Embed Size (px)
DESCRIPTION
In Part 5 of our series on putting CD into practice, we examine a few deployment patterns with their pros and ons
Citation preview
How do you implement
Continuous Delivery?
Part 5: Deployment Patterns
Key Principle:
Low–risk releases are incremental
Why? Low–risk releases are incremental
§ 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…
Blue-Green
Deployment Pattern
http://martinfowler.com/bliki/BlueGreenDeployment.html
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.
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Blue Environment
Release 1
Green Environment
Blue-Green Deployment Pattern
At any time only one production environment, let's say, blue, is live
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Blue Environment
Release 1
Green Environment
Release 2
Blue-Green Deployment Pattern
As you prepare a new release of your software you do your final stage of testing in the green environment.
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Blue Environment
Release 1
Green Environment
Release 2
Blue-Green Deployment Pattern
Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Blue Environment
Release 3
Green Environment
Release 2
Blue-Green Deployment Pattern
The blue environment is now available for you to deploy your next release.
Phoenix
Deployment Pattern
http://kief.com/configuration-drift.html http://martinfowler.com/bliki/PhoenixServer.html
Phoenix Deployment Pattern
§ 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.
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Consider Release 1 on R1 Environment
R1 Environment
Release 1
Phoenix Deployment Pattern
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
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
Router
http://martinfowler.com/bliki/BlueGreenDeployment.html
Kill the R1 Environment
R2 Environment
Release 2
Phoenix Deployment Pattern
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
Environment Promotion
Pattern
?
Environment Promotion Pattern
§ 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.
?
The R2 environment created for Release 2 of the application, is tested in the QA stage
R1 Environment
Release 1
Production Router
UAT
R2 Environment
Release 2
QA Router
Environment Promotion Pattern
?
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
?
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
Canary
Release Pattern
http://www.informit.com/articles/article.aspx?p=1833567 http://techcrunch.com/2011/05/30/facebook-source-code/
Canary Release Pattern
§ 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.
Router
Consider a cluster of servers Canary Release Pattern
R1 R1 R1 R1 R1 R1 R1 R1
R1 R1 R1 R1 R1 R1 R1 R1
R1 R1 R1 R1 R1 R1 R1 R1
Router
Canary Release Pattern
R1 R1 R1 R1 R1 R1 R2 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
Router
Canary Release Pattern
R1 R1 R1 R1 R1 R1 R2 R2
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
Router
Canary Release Pattern
R2 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
Dark Launching
http://www.facebook.com/note.php?note_id=96390263919
Dark Launching § 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.
Router
Rollout the release to all, with the new feature within it being released to only a subset of servers/users
Dark Launching
R1 Release R2 Release
New Feature
R2 Release
New Feature
Router
Only after satisfactory load/stress testing and feedback on the new feature, is the new feature rolled out to all servers/users
Dark Launching
R1 Release R2 Release
New Feature
R2 Release
New Feature
Data Management
Stay tuned for Part 6…
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.
Learn More See how Go can help you in your CD journey
goContinuous Delivery
