Downloaded 76 times
Uploaded byThoughtWorks Studios
How do you implement Continuous Delivery?: Part 5 - Deployment Patterns
The document provides insights on implementing continuous delivery through various low-risk deployment patterns, emphasizing the importance of incremental releases to minimize volatility. Key patterns discussed include blue-green deployment, phoenix deployment, environment promotion, canary releases, and dark launching, each offering strategies to reduce downtime and improve testing efficiency. The document concludes by encouraging the use of automation tools to streamline the delivery process.
More Related Content
Similar to How do you implement Continuous Delivery?: Part 5 - Deployment Patterns
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
How do you implement Continuous Delivery?: Part 5 - Deployment Patterns
- 1. How do youimplement Continuous Delivery? Part 5: Deployment Patterns
- 2. Key Principle: Low–risk releasesare incremental
- 3. Low–risk releases are incremental Why? § Big-bangreleases that involve multiple dependent components, database changes and/or business logic changes are highly volatile. § Instead incremental releases, where the new functionality and all dependent services are thoroughly tested, and rollbacks are easier, are low-risk. § Let’s explore some low-risk incremental deployment patterns…
- 4.
- 5. Blue-Green Deployment Pattern § Minimizing downtime,while doing the “cut-over” from testing to release is one of the key challenges with automating deployment. § The blue-green deployment approach does this by ensuring you have two identical production environments. § It also helps you to rapidly rollback in the event of a failure. http://martinfowler.com/bliki/BlueGreenDeployment.html
- 6. Blue-Green Deployment Pattern At any timeonly one production environment, let's say, blue, is live Router Blue Environment Release 1 http://martinfowler.com/bliki/BlueGreenDeployment.html Green Environment
- 7. Blue-Green Deployment Pattern As you preparea new release of your software you do your final stage of testing in the green environment. Router Blue Environment Green Environment Release 1 Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 8. Blue-Green Deployment Pattern Once the softwareis working in the green environment, you switch the router so that all incoming requests go to the green environment Router Blue Environment Green Environment Release 1 Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 9. Blue-Green Deployment Pattern The blue environmentis now available for you to deploy your next release. Router Blue Environment Green Environment Release 3 Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 10.
- 11. Phoenix Deployment Pattern § Phoenix serversare those that you virtually tear down at regular intervals. § Configuration drift describes inconsistencies between servers caused by ad-hoc changes over time. § Phoenix servers are a great way to avoid configuration drift, as they are rebuilt from a common template, and are not kept running for long enough for much configuration drift to accumulate. http://kief.com/configuration-drift.html http://martinfowler.com/bliki/PhoenixServer.html
- 12. Phoenix Deployment Pattern Consider Release 1on R1 Environment Router R1 Environment Release 1 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 13. Phoenix Deployment Pattern Ready Release 2on the R2 Environment Router R1 Environment R2 Environment Release 1 Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 14. Phoenix Deployment Pattern Switch the routerto the R2 Environment Router R1 Environment R2 Environment Release 1 Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 15. Phoenix Deployment Pattern Kill the R1Environment Router R2 Environment Release 2 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 16. Phoenix Deployment Pattern Continue the processwith the R3 Environment Router R2 Environment R3 Environment Release 2 Release 3 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 17.
- 18. Environment Promotion Pattern § With thispattern, a new environment is created for each software release, and the environment itself is promoted through the stages of the pipeline. § This ensures that the actual environment has been tested, rather than only the changes to the configuration. § This pattern may be inappropriate when an environment needs to be integrated with different external services at different stages of the pipeline. ?
- 19. Environment Promotion Pattern The R2 environmentcreated for Release 2 of the application, is tested in the QA stage QA Router UAT Production Router R2 Environment Release 2 ? R1 Environment Release 1
- 20. Environment Promotion Pattern The R2 environmentis connected to the UAT router, and Release 2 goes through user acceptance testing. QA Router UAT Production Router R2 Environment Release 2 ? R1 Environment Release 1
- 21. Once the R2environment and its software release have passed UAT, the production router is configured to send traffic to it, and the R1 environment is destroyed. Environment Promotion Pattern QA Router Staging R2 Environment Release 2 ? Production Router
- 22.
- 23. Canary Release Pattern § Thisis a variation of blue-green deployment and is applicable when running a cluster of servers. § With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. § This allows you to get feedback from a small subset of users prior to a complete rollout § Like canaries in a coal mine, if a problem is discovered at the initial stages, the build goes no further. http://www.informit.com/articles/article.aspx?p=1833567 http://techcrunch.com/2011/05/30/facebook-source-code/
- 24. Canary Release Pattern Consider acluster of servers Router R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1
- 25. Canary Release Pattern The buildis first routed to a small section of servers/users Router R1 R1 R1 R1 R1 R1 R2 R2 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1
- 26. Canary Release Pattern The releaseis validated with performance testing and multi-variant testing Router R1 R1 R1 R1 R1 R1 R2 R2 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1
- 27. Canary Release Pattern Only afterthe release feedback is positive, is it rolled out to all servers/users Router R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2
- 28.
- 29. Dark Launching § Thisinvolves releasing a new feature to a subset of users, with minimal UI changes, while exercising all the parts of your infrastructure involved in serving that feature. § This pattern is useful for massive, large-scale deployments to simulate load/stress testing. § Dark launching exposes pain points and areas of the infrastructure that need attention prior to the actual launch. http://www.facebook.com/note.php?note_id=96390263919
- 30. Dark Launching Rollout therelease to all, with the new feature within it being released to only a subset of servers/users Router R1 Release R2 Release R2 Release New Feature New Feature
- 31. Dark Launching Only aftersatisfactory load/stress testing and feedback on the new feature, is the new feature rolled out to all servers/users Router R1 Release R2 Release R2 Release New Feature New Feature
- 32. Data Management Stay tunedfor Part 6…
- 33. go Continuous Delivery Learn More Seehow Go can help you in your CD journey Deploy a great product faster. Agile teams deliver working software early and often. Go automates and streamlines the build-test-release cycle for worry-free, continuous delivery of your product.