Continuous Integration vs. Delivery vs. Deployment

Let’s start by looking at the main characteristics of CI and CD, along with their differences.

Continuous integration (CI)

Continuous integration (CI) is the practice of automatically checking your code changes to get rapid feedback on your work. With CI, each time you commit a change, your CI server runs a build and executes automated tests. These tests typically include unit tests, integration tests, and other checks like linting or static analysis. If any stage of the CI process fails, you receive automatic feedback so you can address the issue. The process starts again when you commit a fix.

Continuous delivery vs. continuous deployment

The difference between continuous delivery and continuous deployment lies in the final stage of releasing to production.

With continuous delivery, releasing the build artifact to production requires manual input. The release process is usually fully automated, but someone must decide if and when a particular build will be released. In contrast, with continuous deployment, the build is released to production automatically every time you complete the previous stages of the process.

Choosing between continuous delivery and continuous deployment

Deciding whether continuous delivery or continuous deployment is more suitable depends on your context.

For software products such as mobile apps or APIs, releasing a new version for every successful commit might not be ideal. Instead, you may prefer to release on a scheduled basis or wait until you have a minimum number of changes ready to deploy.

In this case, you can use continuous delivery to verify changes as you make them and preview releases in a pre-production environment. Continuous delivery can also provide an opportunity for manual acceptance testing before each release.

On the other hand, continuous deployment works well for web-based apps and services, where frequent – daily or even hourly – updates are standard.

Continuous deployment enables you to drip-feed updates and get timely feedback. You can also use continuous deployment to run experiments and validate assumptions with real-world users, knowing you can change direction quickly with a new release as needed.

Finally, it’s important to note that you can integrate some manual acceptance and exploratory testing into a continuous deployment process.

Instead of requiring manual checks before every release, you can periodically deploy changes to a staging environment and perform these tests on a weekly (or longer) cycle.

Meanwhile, changes that pass all automated checks can continue to be released to production. If you discover an issue in staging, your automated pipeline ensures you can quickly deploy a fix to production.

CI/CD represents two stages in the process of building, testing, and releasing software.

A CI/CD pipeline is a tool that progressively increases your confidence in your code.

Each successful stage builds your confidence until you’re happy to release the code to users. However, if any stage fails, you stop the build process and must either fix the bug or revert the changes. Once resolved, the process restarts from the beginning.

As the first phase of the build, test, and release process, CI focuses on quick feedback through checks. Rapid feedback on changes to your code helps you work more efficiently by reducing the need for context switching. Instead of waiting hours or days for manual testing results, you receive alerts within minutes about any issues introduced by your changes.

If the build containing your changes passes the CI tests, deploying it to pre-production environments is warranted. At this point, you can perform longer-running and more resource-intensive tests.

Automating as many CD steps as possible further shortens the feedback loop and makes for a more efficient workflow. In addition to automating tests, for example, you can refresh pre-production environments and deploy builds to them automatically.

If you’re new to CI/CD, instead of focusing on choosing between continuous integration and continuous delivery or deployment, we suggest deciding where you want to start and how far you want to go.

Both CI and CD involve multiple steps, meaning you can develop your processes gradually.

Finding your starting point

If you’ve already automated some parts of your build or release process, or if you’ve written automated tests, these can provide a natural starting point. If not, begin by considering which parts of your build, test, and release process are most time-consuming or prone to issues in production due to inadequate testing.

Many teams choose to start with CI because it requires less coordination with other parts of the organization, and the rapid feedback from the automated unit and integration tests helps improve code quality.

Additionally, recognizing CI's benefit helps foster an automated testing culture, which is vital for effective CI/CD and encourages further expansion of automated test coverage.

On the other hand, if you’re currently managing both release coordination and code development, then automating the final stage of CD (the release to production) first can save you time in the long run.

While CI provides a strong base for CD, choosing between continuous delivery and continuous deployment depends on your requirements. Even if your long-term aim is continuous deployment, a typical strategy is to begin with continuous delivery. Once you’ve established confidence in your workflows, you can make the leap to automating the final release to production.

Improving your CI/CD processes

CI and CD work best when you break development tasks into smaller deliverables and regularly commit your changes.

If your goal is continuous deployment, you need to consider how to manage features that aren’t yet ready for release even though changes have been committed for them. You can achieve this by using feature flags or a branching strategy that isolates work-in-progress from the release branch while ensuring you build and test each code change automatically.

To recap:

• Continuous integration (CI) involves running automated tests and checking that your solution builds each time you commit a change.
• Both continuous delivery and continuous deployment (CD) involve deploying build artifacts to testing and staging environments automatically to run further tests. You typically perform these steps after continuous integration.
  • In continuous delivery, you decide when to release a particular build artifact to production and initiate the release manually.
  • In continuous deployment, every code change that passes through the previous stages successfully is automatically released to production.
• CI and CD are complementary practices designed to identify issues quickly and give you confidence in your changes before you release them.
• A robust CI/CD process with automated testing allows you to deploy fixes faster and more confidently if you release any bugs to production.
• A fully automated build, test, and release process consists of both CI and CD, but you can start with just one or the other and build your process incrementally.
  • Many teams start with continuous integration, as automated tests are usually the developers’ responsibility.
  • However, if you’re also responsible for handling releases, automating those first can help save time so that you can focus on building your CI process.