HOW DO YOU IMPLEMENT CONTINUOUS DELIVERY?
Part 5: Deployment Patterns
Share this ebook.
PERSPECTIVES
KEY PRINCIPLE
2
Low-risk releases are incremental
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
BLUE-GREEN DEPLOYMENT PATTERN
4
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
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
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
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
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
PHOENIX DEPLOYMENT PATTERN
10
http://kief.com/configuration-drift.htmlhttp://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
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
17
?
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
?
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
22
http://www.informit.com/articles/article.aspx?p=1833567http://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
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
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
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
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
DARK LAUNCHING
28
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
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
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
DATA MANAGEMENT
32
Stay tuned for part 6
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.