Continuous Deployment

Continuous Deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.

Continuous deployment is controversial. Most people, when they hear about continuous deployment, think I'm advocating low-quality code. On the contrary, I believe that continuous deployment requires tremendous discipline and can greatly enhance software quality, by applying set of standards to every change to prevent regressions.

To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.

Benefits

• Earlier return on investment for each feature after it is developed, which reduces the need for large capital investments

• Earlier feedback from users on each new feature as it is released to production, which affords techniques such as parallel (or A/B) testing to determine which of two possible implementation is preferred by users

Pitfalls

• To the extent that continuous deployment is viewed as a strategy for quality, it's easy (in particular for developers enamored with the novelty and technical aspects of it) to pick the wrong target, and optimize for "maximum frequency of deployments" - that will not, by itself, result in increased quality.