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
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
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
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. ?
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. ?
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. ?
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
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
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. 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. 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
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. 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. 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
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.