Introduction to continuous delivery
- 1. Introduction to Continuous Delivery André Meurer @themeurer Head of Software Engineering @ Olympic
- 2. How long would it take to get a one line code change into production using the current process?
- 5. The “tail period” or “last mile” • Time from code freeze to release – Beta & regression testing – Code integration & integration testing – Documentation – Bug fixing – Deployments
- 6. Continuous Delivery is about reducing risk of releases and making deployments boring
- 7. Reduce risk of releases
- 8. Fast, automated feedback on the production readiness of your application every time there is a change Constant flow of small increments into production Software always production ready
- 9. Key Principles • Constant flow of small incremental changes into prod • Software always production ready • Automate almost everything • Build, deploy, test, release, repeat • Use humans for high value stuff • Manual testing, approvals • Keep everything in source control • If it hurts, do it more often, and bring the pain forward • Done means released in production • Continuous improvement – don’t try to do it all at once
- 10. Build the right thing • Every business idea is just a hypotesis • Most features are rarely or never used • Don’t ask customers what they want: try it out • Release a minimum viable product • Can respond quickly to market demands • Hypotesis – MVP – Analyse – Repeat
- 14. Continuous integration • Early integration • Everyone’s changes integrated frequently in the same place • Build & test at every check-in • Rapid feedback • It’s a practice, not a tool
- 16. The software testing pyramid GUI Acceptance tests Unit & component tests More business-facing Less stable More realistic Lower cost Easier maintenance More stable Faster feedback Exploratory/ manual
- 17. The software testing cupcake anti-pattern
- 18. Trunk based development • Check-in or merge into trunk at least once per day • Feature branches should be short lived • Branches discourage refactoring – People don’t know what code other team members are touching, so they are hesitant to refactor for risk of impact • Branches delay integration and hide risk • Merging wastes time and is tedious
- 19. Inside out development • Build from the bottom – DB – Business Logic – UI • Feature not accessible until full development is complete • Small slices/stories to enable fast feedback
- 20. Feature toggles/switches • Deploy incomplete features switched off – Be aware of feature switch madness – Switches need to be deleted as the feature is in production • Control who can see the new feature – Test it with a small group of users – Ensure it handles the load – Gradually increase group of users if appropriate • Separate deployments from releases
- 22. Branch by abstraction • Parallel routes • Make architectural changes – Interface to create abstraction – Abstraction layers with two working implementations – Swap bit by bit of the code to the new architecture until complete – Old implementation can be removed once no longer used • DB changes – No breaking schema changes until code is ready to deal with new schema
- 23. Roll Forward • Rollback strategy is complex & risky • Easier to fix something and get it through the pipeline
- 24. Canary Releases • Release features to smaller groups/clusters • Test/verify stability/performance/etc. • Roll out to more/rest of users
- 25. Blue Green deployments • Two instances of the production environment – Current PROD (blue) – Upgrade environment (green) • Start routing small groups/clusters of people to Green environment • Swap them
- 26. Quality • QA inspects quality • Everyone is responsible for quality • QA represents the user
- 27. IT ops team close to dev team • Sit together: Dev, QA, and Ops • Have sysadmin as part of the development team • Deploy to all environments the same way we deploy to production
- 28. Delivery Pipeline Tools • Orchestration/CI – Team City – Jenkins – Bamboo • Delivery Manager – LiveRebel – OctopusDeploy • Infrastructure Automation – Chef – Puppet – Bcfg2 – CFEngine
- 29. Where do I start? • Why do you want to do it? • It will take time, start now • CI is first step • Get the architecture right • Culture of continuous improvement • It will need investment
- 30. It’s a journey • Fundamental change to the way most organisations ship software • Releases tied to business needs, not IT constraints • Minimise lead time from idea to live (concept to cash) • IT no longer the bottleneck • Buy-in from client is critical
- 31. Resources • Jez Humble: Continuous Delivery • Patrick Kua: Implementing Continuous Delivery • Facebook: Moving fast at scale • John Allspaw: 10 deploys per day, dev and ops cooperation at Flickr • David Cramer: Practicing Continuous Delivery • Sam Newman: The path to continuous delivery • Rolf Russell: Introduction to Continuous Delivery
Editor's Notes
- #8: Reliability & Stability Shorter mean time to recovery If you have a small set of changes in your release, the set of possible causes is also small Enables you to figure out what the problem is & resolve it very quickly If something is really hard (i.e., releasing software), do it again and again until it becomes second nature. Don’t live with the pain: do it over and over until you are very good at it
- #9: The faster you get feedback, the faster you can fix the problem – the cost of fixing the mistake is minimal
- #17: Trade off Not everything can be a unit test But try to minimise the number of tests towards the top of the pyramid, focusing on as many tests as possible towards the bottom of the pyramid