Pete Marshall - casmadrid2015 - Continuous Delivery in Legacy Environments
2 likes814 views
This document discusses practices for implementing continuous delivery in legacy software environments. It outlines key characteristics of continuous delivery like keeping software deployable throughout its lifecycle. It then provides examples of how one company transitioned their monolithic legacy application to a continuous delivery model by using techniques like the strangler pattern, refactoring to separate concerns, and restructuring their organization into cross-functional product teams. The document emphasizes establishing technical foundations, learning through the build-deploy-learn cycle, and focusing on delivering value to customers.
Pete Marshall - casmadrid2015 - Continuous Delivery in Legacy Environments
- 1. Practices, mechanisms and organisational models that can be applied to any software project, big or small, old or new. Continuous Delivery in a Legacy Environment
- 2. - Technical Architect at Planday - Lead consultant at Lean Software - 16+ Years in software development, based in London & Madrid Peter Marshall MAIL info@leansoftwareservices.com TWITTER @petemar5hall LINKEDIN https://www.linkedin.com/in/petedmarshall
- 3. How many people are practicing continuous delivery or have a devops team/culture?
- 4. How long would it take your organisation to build and safely deploy a change that involved just one small feature or a single line of code?
- 6. “Continuous delivery is about focusing on technical excellence”
- 7. “Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” Martin Fowler, May 30, 2013
- 9. 1. YESTERDAY Your software is deployable throughout its lifecycle Key Characteristics
- 10. 1. YESTERDAY Your team prioritises keeping the software deployable over working on new features Key Characteristics
- 11. You can perform push-button deployments of any version of your software to any environment on demand Key Characteristics
- 12. Anybody can get fast, automated feedback on the state of their systems any time somebody makes a change to them Key Characteristics
- 13. A quick look at
- 14. The Leading Workforce Collaboration Solution for shift based businesses Driven by simple, powerful and beautifully designed SaaS technology
- 15. Healthy & organic growth for 11 years Investment from Creandum in 2014 ($3.75 million) Global expansion Founded in 2004
- 16. 70+ people HQ in Copenhagen Offices in Oslo Aalborg Hanoi London New York
- 17. Founded in 2004 1. YESTERDAY “Conquer the world in the next 12 months!” which translated to: “Move into the USA with the next 6-12 months” “Be ahead of the game, always” “maintain our reputation of producing quality software”
- 18. vs. “to be able to deliver software quick, easily, and with very low risk of failure” “to be able to scale our systems very quickly” Technical Goals
- 19. Web Portal Models & Controllers Business Logic Data Access Salary Scheduler Messaging Services Punchclock REST Sign Up Android iOS Planday Monolith Mobile Databases Supplementary Web Apps .net
- 20. “Always have at least some idea of where you are now, and where you want to go, and share that with the team, organisation, and even customers.”
- 21. Where do you start? First pass.
- 22. Build Agent & Devel The delivery pipeline Pre commit tests Code review PO/UX review Branch / Merge Build Unit tests Contract tests Component tests Coverage Static analysis Component performance End to end component tests NFR tests Exploratory Test performance testing Story sign off / Demos NFRs Analytics Monitoring Production tests canary or blue / green release CI Environments Developer Local Pre-Production Production Virtualised Full stack environments Commit Auto-Deploy Promote Release Build Pipeline: There can be multiple pipelines, usually per system, should execute in minutes Commit: The commit can include changes to the infrastructure, database, or application code. Outputs: Software, infrastructure and configuration Environment manifests Release notes stabilise
- 23. Remove the fear. Remove unnecessary human intervention from the process. Remove the magic.
- 24. Put simple continuous integration in place, with build monitors. Put a simple deployment mechanism in place. Make it easy to clone, build, and commit code.
- 26. Second pass. Improve our knowledge of the state and behaviour of the system.
- 27. Simple environment provisioning. Lets run some tests. Logging and monitoring.
- 28. “A good, easily accessible event & error monitoring system is essential for anyone releasing software. Build an early warning system into your environment!”
- 29. “Understanding your systems steady state allows you to react quickly to any deviation”
- 30. second pass Build & Test Deployment & Provisioning Logging & Monitoring Infrastructure - Environment provisioning
- 31. Back to the business goal. We had stabilised the system, made it easy to work with, and now we had to win the business! Put continuous delivery into ACTION!
- 32. Deliver whatever, whenever. Scale quickly and safely.
- 33. Can we do something with our current monolith? What about microservices, they could solve all our problems, right? we have a lot of user experience experiments to do, we needed to support quick small experiments. quick releasing. Would modern UI frameworks be better to work with than aged .net technologies?
- 34. As a business we knew we would win the game by focusing on user experience, over making or improving existing features
- 35. How we did it
- 37. Web Portal Models & Controllers Business Logic Data Access Salary Scheduler Messaging Services Punchclock REST Sign Up Android iOS Planday Monolith Mobile Databases Supplementary Web Apps
- 38. Existing Planday Monolith Domain Data Mapping / Access Salary Scheduler Messaging Services API WebServer:IIS Android iOS Web Applications Mobile Windows Databases New Front End Modules (JS using REACT) Punchclock Sign UpPortal Existing Front End
- 39. broke direct dependencies Introduced package management Introduced load balancing Introduced caching at the application layer technology geared to rapid developmentincreased logging, monitoring & analysis to cover JS, Server, Database, & Infrastructure adopted domain driven development feature toggling
- 40. Domain + BL Data Mapping + Access Salary Scheduler Messaging Services API WebServer:IIS Android iOS Mobile Windows Databases Client side front end modules Punchclock Sign UpPortal Integration Partners Caching Client side Old Monolith
- 41. Load Balancers Backup Servers VM Hosts Production & Development Database Servers Storage Servers Development Servers Production Servers Repurposed our infrastructure Physical Virtualisation
- 42. Organisation How we restructured the
- 43. CPH Development Team Hanoi Development Team Teams working very much in silos. Unaligned. No process. No management. No attachment to the business. Poor communication. Before Design Team Product Team
- 44. Product Teams Web Mobile API Supporting Teams Dev Ops Tech Management All teams are cross functional with end- to-end responsibility for one or more parts of the system. We use a mixture of scrum and Kanban. Some teams use sprints, others use flow based systems. Common elements occur regardless such as daily standups, estimation sessions, & planning sessions. Our architecture and deployment strategy allow teams to release on their own schedule with minimal impact to others. Virtual teams appear as and when the need arises. After Marketing
- 45. The truth is in the data
- 46. Tech Values
- 47. We value overall simplicity over localised simplicity. We value software developed with a focus on operation and maintenance in production. Deliver in small batches Don't do loads of things
- 48. Development process Build > Deploy > Learn cycle Product requirements are identified by a Product Group and then built by one or more product teams Initiatives that support long term business goal Hypothesis driven with an aim to be proven by specific measurements Feature toggling mechanisms allow experimentation, exploration and controlled feature launches Master Feature Build the feature Toggle it on or off Measure the impact
- 51. Build Agent & Devel Technical Foundations Pre commit tests Code review PO/UX review Branch / Merge Build Unit tests Contract tests Component tests Coverage Static analysis Component performance End to end component tests NFR tests Exploratory Test performance testing Story sign off / Demos NFRs Analytics Monitoring Production tests canary or blue / green release CI Environments Developer Local Pre-Production Production Virtualised Full stack environments Commit Deploy Promote Release Build Pipeline: There can be multiple pipelines, usually per system Commit: The commit can include changes to the infrastructure, database, or application code. Outputs: Software, infrastructure and configuration Environment manifests Release notes
- 52. Learnings We know we will fail sometimes Simplicity is key Common & share vision Strong leadership
- 53. Thank you! TWITTER @petemar5hall Agile Consultant & Technical Architect @planday Peter Marshall fiveMAIL info@leansoftwareservices.com LINKEDIN https://www.linkedin.com/in/ petedmarshall