How do you implement Continuous Delivery?: Part 5 - Deployment Patterns

5,193 views

Published on

In Part 5 of our series on putting CD into practice, we examine a few deployment patterns with their pros and ons

Published in: Technology

How do you implement Continuous Delivery?: Part 5 - Deployment Patterns

  1. 1. HOW DO YOU IMPLEMENT CONTINUOUS DELIVERY? Part 5: Deployment Patterns Share this ebook. PERSPECTIVES
  2. 2. KEY PRINCIPLE 2 Low-risk releases are incremental
  3. 3. Why?  Big-bang releases 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… Low-risk releases are incremental
  4. 4. BLUE-GREEN DEPLOYMENT PATTERN 4
  5. 5. http://martinfowler.com/bliki/BlueGreenDeployment.html  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. Blue-Green Deployment Pattern
  6. 6. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Blue Environment Release 1 Green Environment At any time only one production environment, let's say, blue, is live Blue-Green Deployment Pattern
  7. 7. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Blue Environment Release 1 Green Environment Release 2 As you prepare a new release of your software you do your final stage of testing in the green environment. Blue-Green Deployment Pattern
  8. 8. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Blue Environment Release 1 Green Environment Release 2 Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment Blue-Green Deployment Pattern
  9. 9. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Blue Environment Release 3 Green Environment Release 2 The blue environment is now available for you to deploy your next release. Blue-Green Deployment Pattern
  10. 10. PHOENIX DEPLOYMENT PATTERN 10
  11. 11. http://kief.com/configuration-drift.html http://martinfowler.com/bliki/PhoenixServer.html  Phoenix servers are 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. Phoenix Deployment Pattern
  12. 12. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Consider Release 1 on R1 Environment R1 Environment Release 1 Phoenix Deployment Pattern
  13. 13. Router http://martinfowler.com/bliki/BlueGreenDeployment.html R1 Environment Release 1 R2 Environment Release 2 Ready Release 2 on the R2 Environment Phoenix Deployment Pattern
  14. 14. Router http://martinfowler.com/bliki/BlueGreenDeployment.html R1 Environment Release 1 R2 Environment Release 2 Switch the router to the R2 Environment Phoenix Deployment Pattern
  15. 15. Router http://martinfowler.com/bliki/BlueGreenDeployment.html Kill the R1 Environment R2 Environment Release 2 Phoenix Deployment Pattern
  16. 16. Router http://martinfowler.com/bliki/BlueGreenDeployment.html R2 Environment Release 2 R3 Environment Release 3 Continue the process with the R3 Environment Phoenix Deployment Pattern
  17. 17. ENVIRONMENT PROMOTION PATTERN 17
  18. 18. ?  With this pattern, 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. Environment Promotion Pattern
  19. 19. ? The R2 environment created for Release 2 of the application, is tested in the QA stage R1 Environment Release 1 Productio n Router UAT R2 Environment Release 2 QA Router Environment Promotion Pattern
  20. 20. ? The R2 environment is connected to the UAT router, and Release 2 goes through user acceptance testing. Production Router QA Router UAT R1 Environment Release 1 R2 Environment Release 2 Environment Promotion Pattern
  21. 21. ? Once the R2 environment and its software release have passed UAT, the production router is configured to send traffic to it, and the R1 environment is destroyed. Production Router QA Router Staging R2 Environment Release 2 Environment Promotion Pattern
  22. 22. CANARY RELEASE PATTERN 22
  23. 23. http://www.informit.com/articles/article.aspx?p=1833567 http://techcrunch.com/2011/05/30/facebook-source-code/  This is 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. Canary Release Pattern
  24. 24. Router Consider a cluster of servers R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 Canary Release Pattern
  25. 25. Router R1 R1 R1 R1 R1 R1 R2 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 The build is first routed to a small section of servers/users Canary Release Pattern R2
  26. 26. Router R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 The release is validated with performance testing and multi-variant testing Canary Release Pattern R2 R2
  27. 27. R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 Only after the release feedback is positive, is it rolled out to all servers/users Canary Release Pattern Router R2 R2R2 R2
  28. 28. DARK LAUNCHING 28
  29. 29. http://www.facebook.com/note.php?note_id=96390263919  This involves 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. Dark Launching
  30. 30. Router Rollout the release to all, with the new feature within it being released to only a subset of servers/users R1 Release R2 Release New Feature R2 Release New Feature Dark Launching
  31. 31. Router Only after satisfactory load/stress testing and feedback on the new feature, is the new feature rolled out to all servers/users R1 Release R2 Release New Feature R2 Release New Feature Dark Launching
  32. 32. DATA MANAGEMENT 32 Stay tuned for part 6
  33. 33. LEARN MORE 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. Share this ebook. Visit our Continuous Delivery Channel for more posts like this.

×