This content is part of the Essential Guide: Simplify the production deployment process with these tips
Manage Learn to apply best practices and optimize your operations.

Understand continuous delivery and continuous deployment

Learn why it is important to understand the differences between continuous delivery and deployment. Expert Matt Heusser discusses how they work with one another.

Continuous delivery and continuous deployment could be the most confused terms in software teams. A dictionary would tell you there isn't much difference between delivery and deployment, but the distinction matters.

This distinction between the two, while not quite razor-thin, is tight. TechTarget's own definitions of the terms hinge on one small difference. With continuous delivery (CD), any change that passes all tests becomes a candidate for production deployment. With continuous deployment, the change rolls out automatically when all tests pass.

Continuous similarities

Both continuous delivery and continuous deployment rely on a continuous integration (CI) pipeline. CI produces software code builds that have everything necessary to go to production. Experienced CI/CD organizations tend to have the pipeline rapidly produce a full, stand-alone test environment, either automatically or with minor manual intervention. The tester can see that a build associated with a completed feature passed and then pull up the changes for just that feature, test them and approve the changes for production. Once the tester approves code for production, it kicks off an automated process of deployment. In a continuous deployment setup, that kickoff happens automatically if the tests run.

Both continuous delivery and continuous deployment setups need automated deployment, along with automated rollback. IT organizations must invest in an exhaustive set of automated tooling or establish processes to deploy just small subcomponents that carry minor risk. Both continuous delivery and deployment typically require a focus on monitoring and rollback capabilities.

Development practices under the delivery and deployment techniques are similar. Programmers make changes to code, run unit and possibly integration tests locally and then commit and push those changes to a mainline. Some large, complex organizations use intermediate branches, but most teams have programmers commit every change to a single master branch. Getting to continuous deployment takes some work.

Make continuous deployment work

It's been nearly 10 years since Michael Bolton reviewed IMVU, one of the first organizations to publicly claim to be using continuous deployment. Bolton's concern was not that the team deployed 50 times a day. No, he could believe that. His concern was that a team that removed the human element from testing could deliver quality software. To summarize his findings: What he found wasn't very good.

Today, there are some domains where continuous deployment can be effective. Obviously, free software, paid for by advertisers, such as social media, is one area -- although both Google and Facebook engineers have told me at various times that the serving of advertisements on those platforms, the moneymakers, have a more rigorous change control process.

In practice, continuous deployment requires many more steps. An IMVU executive responded to Bolton's post, saying the company did have a tester involved in process all along and changes were rolled out gradually using A/B split testing.

Testers work with the programmer, periodically switching to test during the development process itself. By the time the code is pushed into version control, it has already been tested.

Rolling changes through split testing is another way to implement this. With simple A/B split testing, the users see two different behaviors, while the company tracks response -- whatever users are more engaged with wins.

For continuous deployment, it's common to put users into categories, such as testers, employees, beta users, power users and everyone. The programmer writes a new feature in this way:

if (feature_is_turned_on("featurename",GetUserType()) {


} else {



One term for this is configuration flag. A database stores the combination of features and on/off flags; feature_is_turned_on takes the information, does a lookup and returns true or false. The authors of How We Test Software At Microsoft -- Alan Page, Ken Johnston and BJ Rollison -- referred to this as "testing in production" and said that a server should look up which version of the software to run based on the user type. If the feature flags are stored in a file or database, then flipping them off -- and thus "rolling the code back" -- can be as easy as updating a database or changing a file.

Another common way to do continuous deployment with configuration flags is to only have it available to privileged users, such as the development team. When testers go to the website and log in as privileged users, they see the new code running and test there. Once testing is complete, the flag gets flipped to on for all users. This greatly reduces the need for a test environment.

Programmers can make an error in the setup of the configuration flag and roll the changes out to all users, or there could be some other problem. In practice, teams that can identify these errors and recover quickly can be remarkably successful despite this risk.

To continuously deploy or deliver?

The core difference between continuous delivery and continuous deployment is that, under CD, there is an intermediate check step. Your team might want this if there is a need to batch features together in a single release, if the risk of deploying to production is too high or if the team does not have the monitoring, rollback or component architecture in place. For example, a team working at a bank might want to continuously deliver to a staging server but have a formal audit process in place before deploying to production. Teams delivering mobile applications through a store that has a multiday rollout might want to slow the pace of deployment because an error that slips through could take days to fix.

A team that tends to deliver buggy software will want to first figure out how to deliver high-quality software to staging, using CD. Once staging is reliable, it's time to figure out how to push that process onto production.

Dig Deeper on CICD in software development