DevOps culture in a BANK

DevOps is all about people and their mindset. Changing mindset is hard, however, following some practices does help to achieved the desired goals. Principles/practices like:
1. Form small cross-functional team driven by objective and measurable goals
2. Empower the team to take decisions
3. Don't penalize failures but celebrate Post-Mortems
4. Change the work environment with less cabins into flat staructure
5. Track the progress of teams enablement

And in the end: You touch it, you improve it!

Transcript

1. @toamit @toamit
2. @toamit Transformation journey in a BANK
3. @toamit
4. @toamit
5. @toamit Bank IT Banks are designed for cost efficiency & stability
6. @toamit
7. @toamit
8. @toamit Agile development Cross functional culture DevOps and Continuous Delivery Microservices architecture Digital talent management Light-weight governance Speed Flexibility
9. @toamit DevOps culture in BTPN
10. @toamit We are a unique bank, whose focus is to serve and empower the mass market segment, a vital segment for Indonesia’s economy. Our latest digital businesses (BTPN Wow! And Jenius) show our passion in digital and innovation. We are continuously bringing such innovations to build a leading mass-market bank, powered by digital.
11. @toamit
12. @toamit
13. @toamit Go beyond, You build it, You run it!
14. @toamit You touch it, you improve it
15. @toamit FAIL FAST, FAIL CHEAP!
16. @toamit Culture of Post-Mortem https://landing.google.com/sre/book/chapters/postmortem-culture.html The cost of failure is education Devin Carraway
17. @toamit New way of working and different breed of bankers
18. @toamit Three approaches to transform operating models to DevOps depending on aspiration and current organization starting point
19. @toamit Failure to expand, lab isolation can cause too much separation from the rest of organization 1 - Start small but have E2E model, capabilities & tools - Make it the lighthouse to inspire organization - Scale to cover larger parts
20. @toamit Slow adoption caused by cautious approach to transformation 2 - Start at a team level with small waves of increments - Implement operating model changes in spikes in parallel to waves
21. @toamit Prolonged disruption caused by incorrect new operating model or lack of capabilities to implement it properly 3 - Design and implement Org Structures for stable & self-contained DevOps teams
22. @toamit
23. @toamit KOPASSUS
24. @toamit Objectives and measurable goals
25. @toamit Team Story Wall
26. @toamit Developer manifesto helps drive coding excellence throughout the development cycle I use the Github Flow philosophy at software development All features are built in their own branches All commits are squashed I open a pull request with the squashed commit to the master Once the request has been reviewed/ merged, I delete the branch At all stages, I make sure I don't break any tests. Everything that's not needed in the repo should be added to .gitignore
27. @toamit Full Continuous Delivery pipeline has been established to push to production in less than 10 minutes SIT/ UAT Live/ Production Environment Developer machine Continuous Integration Continuous Delivery (CAKRA) Master (Cluster) Slave (Linux) Slave (buddybuild) NodeJS/ Java Job Mobile Job Developer Develop-Build-Test Cycle Publishes for both Android & iOS Time duration < 10mins from code commit to production deployment
28. @toamit Cakra – centralize platform for Continuous Delivery Image registry 1 GITLAB NEXUS JENKINS CAKRA Source of truth for code, application version 2 3 4 5 1 Artifact storage repository, versioning of artifacts 2 Orchestrator of pipeline, template for various stages in the pipeline 3 Version of the services deployed across various environments 4 Trigger deployment by pushing image to registry 5
29. @toamit From 2 weeks to 30 mins Openshift setup DC1 DC2 OCP- MASTER OCP- MASTER OCP- MASTER OCP- MASTER OCP- MASTER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER OCP- WORKER JENKINS SLAVE- CLUSTER ANSIBLE- SLAVE OCP- INFRA OCP- INFRA OCP- INFRA OCP- INFRA OCP- INFRA OCP- LOGGER OCP- LOGGER OCP- LOGGER OCP- LOGGER OCP- LOGGER Trigger build Push Ansible Playbook Create OCP Cluster
30. @toamit Description Funct- ional tests API tests Data used Frequency ▪ Test individual units of code (e.g., modules, methods, logic, etc.) Unit tests ▪ Mocked test data ▪ Every story ▪ Load test all read APIs with 10TPS, burst test with 2000TPS, resilience and infrastructure capacity under high concurrent user load Performance tests ▪ Real API data ▪ Every sprint ▪ Test security vulnerability on site (e.g., cross site scripting, etc.) Security tests ▪ Real API data ▪ Every release End to end tests ▪ Test end to end scenario simulating a user journey (e.g., navigating from homescreen to activate package, etc.) ▪ Real API data ▪ Once sprint ▪ Test story level acceptance criteria (e.g., validation of credit card field to back card inputs, etc.) Story tests ▪ Mocked test data ▪ Every story ▪ Test API response format and data against ‘mocked’ test data (e.g., user journey from login to purchase, etc.) Mocked test data ▪ Mocked test data ▪ Every story ▪ Real API data ▪ Every story ▪ Test API response format and data against real data (e.g., user journey from login to purchase etc.) Real API data Type Comprehensive automated tests to enable high quality weekly sprints
31. @toamit Weekly visual performance management dashboard to measure continuous improvements Greater than -75% Less than - 40% Within +/- 60% Measure Measure Measure Measure Quality GPA Test Coverage Test Coverage Test Coverage Category Category Category Category Code Quality UI API Others Application Area Area Module UI API Others Statements Branches Functions Lines Overall Component 1 Component 2 Component 3 Component 4 This Sprint This Sprint This Sprint This Sprint 3.6 3.5 2.8 83% 68% 67% 66% 97% 91% 87% 65% 65% Previous Sprint Previous Sprint Previous Sprint Previous Sprint 3.9 3.3 2.6 71% 66% 64% 61% 97% 91% 87% 65% 65% Target Target Target Target 3.5 3.5 3.0 80% 80% 80% 80% 80% 80% 80% 80% 80% Target Target Target Target
32. @toamit Continuous Delivery is not only Build-Test-Deploy cycle but also defining monitoring /operational KPI and tracking them continuously to measure performance Analytical Operational Dashboard Monitoring and performance dashboard
33. @toamit Keep track of all capabilities needed for DevOps transition and not ‘cherry-pick’ Completely implemented Partially implemented Not implemented Continuous integration Single source version control Frequent code integration Automated feedback loops Automated build & deployment Automated code reviews Automated testing Cross browser tests Unit tests Integration tests Performance tests Security tests Functional tests Infrastructure provision & configuration Network management Automated provisioning Configuration management Capacity Management Service Level management Security & compliance IT security & compliance Availability management Continuity management Access/Identity management Risk management Monitoring & logging Code quality report Integrated system logging Site performance Test code coverage report Site monitoring
34. @toamit
35. @toamit DevOps isn’t something you can buy – it’s something you have to do, and you have to do it yourself John Michelsen, CTO, CA Technologies
36. @toamit A computer shall not harm your work or, through inaction, allow your work to come to harm Jef Raskin
37. @toamit IN OUR JOURNEY • Solution Architect • Scrum Master • Front-end Senior Developer • Back-end Senior Developer • Quality Assurance Engineer recruitment@btpn.com JOIN US