Downloaded 54 times
Uploaded byPavel Chunyayev
You don’t need DTAP + Backbase implementation - Amsterdam 17-12-2015
The document discusses a presentation by Pavel Chunyayev at the Backbase DevOps Amsterdam meetup, focusing on immutable infrastructure and its role in achieving continuous delivery. It highlights the limitations of traditional DTAP (Development, Testing, Acceptance, Production) environments and advocates for a paradigm shift towards on-demand, disposable environments that enhance efficiency and reliability in software deployment. Key takeaways emphasize the importance of quality integration, automation, and a collaborative culture in software development processes.
More Related Content
Similar to You don’t need DTAP + Backbase implementation - Amsterdam 17-12-2015
You don’t need DTAP + Backbase implementation - Amsterdam 17-12-2015
- 1. You don’t needDTAP DevOps and Continuous Delivery at Backbase DevOps Amsterdam meetup, 17-12-2015 Backbase, Amsterdam Pavel Chunyayev
- 3. @PavelChunyayev Amsterdam Levi9 HQ Amsterdam –2005 25 people Novi Sad Serbia Novi Sad – 2005 320+ people Zrenjanin Serbia Zrenjanin– 2014 30+ people Iasi Romania Iasi – 2007 80+ people Kiev Ukraine Kiev – 2008 130+ people
- 4.
- 5. @PavelChunyayev Customer satisfaction 2015 •4th year great results in Outsourcing Performance study • 2015: 100% customer recommendation score Excellent trust score
- 7. @PavelChunyayev Forester Wave: Omni channel BankingSolutions Q3‘15
- 8.
- 9.
- 10. @PavelChunyayev Top 10 companies inNL with best work-life balance
- 11. @PavelChunyayev About me • 11years of IT experience • Lived and worked in Ukraine and Estonia • Moved a year ago to the Netherlands • Learning Dutch • Love cycling • De Holandse 100 • https://www.dehollandse100.nl/actie/pavel-chunyayev
- 12.
- 13. Safely, rapidly andpredictably deliver new features to production
- 14.
- 15.
- 16. @PavelChunyayev Journey across environments DevelopmentTesting Acceptance Production
- 17. @PavelChunyayev DTAP is history •It was hard to create infrastructure -> we had to reuse it • Manually provisioned environments • Took a lot of time • Ticket to system administrator • Nightmare for both parties • End up with golden images • Fixed set of environments • Name them • Configure once • Maybe even automate deployment
- 18. @PavelChunyayev DTAP is evil •Configuration drift • Environments have nothing to do with production • With time they move more and more apart • Dirty environments • Undocumented, forgotten hacks • No one can recreate environment as no one knows how to configure them • Testing is complicated • Different bugs on different environments
- 19.
- 20. You don’t needDTAP
- 21.
- 22.
- 23.
- 24. @PavelChunyayev Change in paradigm •Change in paradigm of the way software is built, shipped and managed • No more static infrastructure • Provision and create infrastructure just in time when it’s needed • And then throw it away
- 25. Create • Use• Dispose
- 26. @PavelChunyayev Never change again •Never touch or change the running system. • No configuration changes • No complicated update processed • Any change = new deploy • Create infrastructure right before deployment • You always start from the scratch • Identical process • No more dirty environments • Does it matter how environment is called if the deployment process is identical?
- 27. @PavelChunyayev Variability • Variability isenemy • Manufacturing: Six sigma • How to deliver environments at scale?
- 28. @PavelChunyayev Prerequisites • Cloud • Manageinfrastructure lifecycle as code / through API • Docker containers • Automate the setup and deployment of your application
- 29. @PavelChunyayev Continuous Delivery • Immutableinfrastructure enables CD Build • Test • Deploy • When you want to change - go through the whole pipeline
- 30. @PavelChunyayev Infrastructure is integralpart of application • Application is delivered as a set of immutable virtual machines or containers. • Any change in the application is actually a change of infrastructure • Exactly the same process to deploy any version of the application • MTTR is predictable • It’s time required for whole pipeline execution • Gives incentive to optimize the process in order to speed it up
- 31. @PavelChunyayev Immutable infrastructure appliesto • Stateless applications • State is stored outside (DB) • Even more relevant for microservices • Pushing of responsibility to someone else • Databases • Separate DBMS from data • There are solutions for this (e.g. Flocker)
- 32. @PavelChunyayev Deliverables • Server images(AMIs) or containers should be built using automated CI/CD process • Base image + application = deliverable • Or the configuration process and deployment scripts are applied over and over again
- 33. @PavelChunyayev Deliverables • Create yourown images, don't reuse someone else's • Images must be versioned and all history must be saved • Implement automated testing of infrastructure • Create building blocks • Test deployments without any fear • Deployments are automated • Identical deployment procedures to all environments • Green/blue, canary and rolling deployments
- 34. @PavelChunyayev Immutable infrastructure • Getinfrastructure exactly when it’s needed • Dispose immediately after use • Never regret
- 35. Continuous Delivery atBackbase And immutable infrastructure
- 36. @PavelChunyayev Backbase • Research andDevelopment • Professional Services Customer Experience Platform Launchpad Mobile SDK Digital Banking Services Digital Banking Platform
- 37.
- 38. @PavelChunyayev Publishing • Multiserver configurationis needed to test publishing Editorial Staging Live
- 39. @PavelChunyayev Dual deployment model •Cloud Native first • But bank are not ready • Dual deployment model • Containers/cloud – modern • Enterprise style
- 40. @PavelChunyayev Teams structure • Squads •Team is divided into squads • Each squad is responsible for one or more components • Components • Components = microservices • >10 BE components • Dozens of FE components • Continuous Delivery squad is a Platform team
- 41. @PavelChunyayev Platform team • Nowconsists of 4 people, 5th starting in January • You can be part of this team • Several generations of platform • We are in the middle of introduction 4th generation
- 42. @PavelChunyayev Generations 1. Infrastructure asa service MVP 2. All configurations for CXP 5.6 and testing at scale 3. Docker and microservices support 4. Unified way of delivering infrastructure (being rolled out)
- 43. @PavelChunyayev Development environments • Dockercontainers = building blocks • Docker Machine • Docker Compose • No need to use virtual machines • No need to use jetty and h2 • No need to start whole environment
- 44. @PavelChunyayev Building blocks • Ansibleroles • Packer • Infrastructure testing • Before – Starting full environments • Now – Testing roles in isolation • Test-kitchen • Serverspec
- 45. @PavelChunyayev Delivery pipelines git BuildVersion Test Release Component 1 git Build Version Test Release Component 2 git Build Version Test Release Component 3 Assemble CXP Test Release 342 128 473 921
- 46. @PavelChunyayev Pipelines as code •Pipelines as code • Changes -> same process as code changes • First stage is enforcing specifications • GoCD + Gomatic (updated) • https://github.com/Backbase/gomatic
- 47. @PavelChunyayev Platform • Services tomanage environments lifecycle • The same way for everyone • Autoconfig • AWS • Autodocker • Docker
- 48. @PavelChunyayev Autodocker • Swarm cluster •Interface for docker environments provisioning • Limitations • One host for networking • Memory checks • Destruction after TTL • Configuration is a docker compose file • Start exact version of your component and released version of all other components
- 49. @PavelChunyayev Autoconfig • AWS on-demandmulti-server environments • Any application version • Any configuration option • JSON (Form data) with parameters { "server": "jboss", "database": "oracle", "universal_collection": "true", "htts": "true" }
- 50. @PavelChunyayev Autoconfig APIs • GET/api/stacks - List stacks available for provisioning • GET /api/environments - List all currently provisioned environments • POST /api/stacks/<stack_name> - Provision specified stack • DELETE /api/environments/<environment_id> - Destroy environment with specified id • DELETE /api/environments/all - Destroy all environments
- 51. @PavelChunyayev Autodocker APIs • POST/api/docker - create new docker environment • GET /api/docker/<env-name> - get info about specified environment • GET /api/docker - get info about docker environments provisioned by the user Optional parameters: • all_users = True • uptime (value in hours) • owner (AD username) • DELETE /api/docker/<env-name> - delete specified docker environment • DELETE /api/docker - remove docker environments provisioned by the user Optional parameters: • all_users = True • uptime (value in hours) • owner (AD username)
- 52. @PavelChunyayev Quality • Build thequality in the process • Move tests to the left • Testing pyramid • No more manual testing • Ideal testing framework • Manage parallelism • Create environments M E2E Contract Component Integration Unit
- 53. @PavelChunyayev Releasing • Banks don’twant frequent releases • 3 stage release process • Rolling • In the effort to not release too infrequently • Technical previews • At the end of every sprint • Marketing releases • When product manager decides to release
- 54. @PavelChunyayev Culture • No blaming,no fingerpointing • Failing the build is a learning opportunity • We failed a lot • Several iterations of JS deployments • Visibility • Shared responsibility • Squad – for component delivery • Tribe – for product delivery
- 55. @PavelChunyayev Key takeaways • Forgetabout DTAP • Believe in immutable infrastructure • Create repeatable and reliable process for releasing software • Build quality in • Improve continuously Any questions? pavel@levi9.com