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.