Continuous Delivery

Patterns / Antipatterns

Christoph Schleifer - Twitter: @slueg

Merge Daily

Pattern:

Anti-Patterns:

changes commited to the mainline are applied to each branch on at least daily basis.

• Merging iterated mainline before merging into it
• Merging on a weekly basis

Single Command Env.

Pattern:

Anti-Patterns:

run a single command to build and deploy the application to any accessible environment, including the local development

• Forcing the developer to define and configure environment variables
• Make the developer install numerous tools

Single Path to Production

Pattern:

Anti-Patterns:

configuration management of the entire system (source, configuration, environment, data)

any change is a revision in the vcs

• parts of the system are not versioned
• configuration of the system is done manually

Build Threshold

Pattern:

Anti-Patterns:

fail a build when a project rule is violated - e.g. slow tests, coding standards violations, …

• manual code reviews
• learning code quality issues later in the development cycle

Stop the line

Pattern:

Anti-Patterns:

fix software delivery errors asap - stop the line!

no one checks in on a broken build as the fix becomes highest priority

• builds stay broken for long periods of time
• developers can not check out functioning code all the time

Value-Stream Map

Pattern:

Anti-Patterns:

create a map illustrating the deployment process from check-in to release

• tribe knowledge

common language

Pattern:

Anti-Patterns:

agree upon a common scripting language (python, ruby,…)

• different script languages

fail fast

Pattern:

Anti-Patterns:

fail the build as soon as possible. scripts that fail more often should run first and should run as part of the commit stage

• common build mistakes are not uncovered until late in the deployment process

Fast Builds

Pattern:

Anti-Patterns:

the build process provides feedback on common problems as quickly as possible (< 10 minutes)

• do everything in the commit stage process, like running every automated static analysis tool or running load tests

Scripted Deployment

Pattern:

Anti-Patterns:

All deployment processes are written in a script, checked in to the VCS and run as part of the single delivery system

• documentation is used instead of automation

Unified Deployment

Pattern:

Anti-Patterns:

the same deployment script is used for each deployment

• different scripts for each target environment
• manual configuration after deploy for each target

Rollback Release

Pattern:

Anti-Patterns:

provide an automated single command to rollback changes after an unsuccessful deployment

• manually undoing changes

Self Service Deployment

Pattern:

Anti-Patterns:

anyone can deploy to any enironment (except for permissions)

• only on person is responsible for deployments

Automate Provisioning

Pattern:

Anti-Patterns:

automate the configuration of environments to include infrastructure

• configured servers are "work of art" requiring manual steps to provision them

Production-Like Environments

Pattern:

Anti-Patterns:

target environments are as similar to production as possible

• environments are manually configured
• local development envs are not production-like

Toggle Features

Pattern:

Anti-Patterns:

deploy new features or services to production but limit access dynamically for testing purposes

• waiting a feature is fully complete before committing the source code

Cross-Functional Teams

Pattern:

Anti-Patterns:

Everybody is responsible for the delivery process

• siloed teams

You build it, you run it

Root-Cause Analysis

Pattern:

Anti-Patterns:

learn the root cause by asking "why" of each answer until discovering the root cause

• accepting symptoms as the root cause

References

https://dzone.com/refcardz/continuous-delivery-patterns