Continuous Integration vs Continuous Delivery vs Continuous Deployment

CI/CD is always referred to as the ideal solution for a build pipeline, but what does that actually mean? How do you achieve CI/CD in its original definition?

In this post I will refer to mainline, which is the branch of the code base with the most up to date code, where developers push to, and pull from.

Continuous Integration (CI)

CI was championed by Kent Beck back in 1996 as part of Extreme Programming, and was originally intended to focus on one single integration point for the development team, and for each developer to integrate to mainline at least once a day.

The idea is that this will lead to multiple integrations per day, faster discovery of bugs, less conflicts and less chance of duplication of work. These should all lead to faster software development.

To determine if your team is practicing CI, ask yourself these 3 questions, which Martin Fowler and Jez Humble talk about:

1. Does every developer on your team commit and push to a shared mainline at least once a day?
2. Does each of these commits cause a build and test?
3. When the build fails, is it usually back to passing within 10 minutes of first failing?

If the answer to each of these questions is yes, then you’re probably practicing CI in its original form. To further clarify, here is what I see when a team is practicing CI according to Kent Beck:

• You use a version control system to store and version your source code
• Your build is completely automated and is kicked off when a developer pushes a commit to the mainline
• Your build is self testing, meaning a suite of tests run against the committed code and in a test environment
• Your build is fast (less than 30 minutes)
• You can fix a broken build in less than 10 minutes
• Your deployments are automatic (you don’t have to deploy to production on a commit to mainline, but your deployments don’t require more than one button click)

Like me when I first dug deep into this, you may be asking the following questions:

Does this mean feature branches are not a practice in Continuous Integration?

Yes, that’s correct. Because developers are committing to mainline multiple times a day, feature branches are not usually required, and will only slow down development. The idea of developers working on feature branches for days contradicts continuous integration, as their code is only being integrated after a feature is developed, which is usually more than a days work.

If feature branches are to be used in continuous integration, they will be extremely short lived branches, probably only alive for a few hours before being committed to mainline.

CI version control integrations

The above figure shows how developers are constantly committing to mainline, without the need for feature branches.

Hold on, so if there’s no feature branches, what about code reviews?!

If you go by Kent Beck’s original idea of continuous integration from Extreme Programming, there are no code reviews, that’s why there needs to be an emphasis on ensuring that developers are disciplined and hold their code to a high degree of quality.

Extreme programming introduced the idea of pair programming, meaning that code was being reviewed on the fly. Adding code reviews can potentially add a bottle neck to development, and therefore slow down a teams overall development pace.

Here is a snippet straight from Extreme Programming:

An interesting concept — code reviews are generally intended to:

1. Verify the correct functioning of production code.
2. Ensure that agreed-upon standards are followed.
3. Promulgate understanding of code throughout a project.

“I can see that the 1st point is adequately handled via unit tests, the second via collective code ownership, and the third through pair programming; However, there still seems to be something missing here: how do you ensure that the unit tests actually test the added functionality? Don’t the tests themselves need to be reviewed?”

The answer to this question comes down to Test Driven Development (TDD). If your team has a standard practice of writing unit tests first, then unit testing will become a first class citizen, and therefore your code should always include high quality tests.

Continuous Delivery (CD)

Continuous delivery is a lot easier to explain than continuous integration. Simple put, continuous delivery states that:

Your software can be released to production at any given time.

Here are some questions, which if you answer yes to all, suggests you’re doing continuous delivery:

1. Can you release to production right now?
2. Can you deploy to production with the click of one button?
3. Does your team prioritize keeping your software deployable over working on new features?

Practicing continuous integration is seen as a prerequisite to continuous delivery. If you’re practicing CI, it shouldn’t be a massive lead to practice CD. Although, you don’t need to be practicing CI to have CD. Your software may always be deployable even if you aren’t continuously integrating your code with other developers.

Continuous Deployment (CD)

Continuous deployment goes one step further, and releases to production after the build passes on a commit to mainline.

Let’s take a look at a common CI/CD pipeline, where CD in this case refers to continuous deployment:

CI/CD pipeline

1. The developer makes a commit to mainline.
2. On this commit, a build will be triggered.
3. This build will occur, running things like linting, code analysis and unit tests.
4. Run tests on development environment.
5. Once the tests all pass in this environment, deploy to QA.
6. Run the tests again against the QA environment.
7. If the tests pass in QA, deploy to production.
8. Run the suite of tests against production.

It’s important to note that if the tests fail in any of the different environments, it should stop the build and ideally, you should be able to automatically roll back to the previous working version of your application. This will result in minimal downtime.

It’s also important to note that addition to the steps above, there should be monitoring and alerting built around the pipeline, to ensure the team can respond to build failures as quickly as possible.

Should we strive for Continuous Deployment?

Where possible, continuous deployment is ideal, it will result in faster development, higher quality products and faster feedback. But continuous deployment is not always feasible.

Think of the scenario of a mobile or desktop app. These apps all need to be reviewed by the platform (Google/Apple) before being released. Plus, you don’t want users of your app to receive multiple updates every day, so continuous delivery is probably the best solution for these types of applications.