Continuous integration
and continuous delivery

Continuous integration and continuous delivery

Choosing between continuous integration and continuous delivery

Continuous integration (CI) and continuous delivery (CD) are a set of practices to implement and deliver code changes fast and reliably over the course of application development.

These techniques are considered to be the best principles for the teams to drive efficiency into software engineering. Both techniques have their own benefits. However, different types of projects require different approaches – whether to choose just CI, combine CI and CD or go without these practices for build and delivery automation.

Continuous integration

Continuous integration implies the systematic verification of code changes and their compliance with the requirements set on a project. This verification may include unit tests, static code analysis and any other checks adopted by the team.

This practice is continuous because verifications are implemented at every committed code change. Therefore, it provides the consistency of the development process and ensures the better quality of the final software product.

After each verification cycle is complete, the code is ready for the integration and deployment. The product of integration – build artifacts – can have different forms such as compiled binaries, web package or docker image.

When to use continuous integration alone

In my experience, the practice of continuous integration alone is better used when:

  • the project is not very large and does not require complex deployment,
  • deployment is rare,
  • deployment is implemented by a third party,
  • we are building a mobile app.

 

Continuous delivery

Continuous delivery is the second stage of continuous integration that enables automated delivery and deployment. Thus, continuous delivery is impossible without prior integration, whereas continuous integration can be adopted as an independent technique.

The practice of continuous delivery implies automatic deployment of build artifacts to test, demo and staging servers or directly on production. In other words, all verified changes go through the process of delivery immediately after they’ve been tested and don’t require manual intervention to the system from developers.

In this context, the changes are considered to be ready for deployment for different reasons. For example, CD may be triggered by the QA’a status saying all the bugs are verified and features are tested. It can be validated by completed autotests or even the permission from a product owner or other decision maker on a project.

When to use continuous delivery

Usually, we prefer continuous delivery over continuous integration when:

  • we are dealing with a complex system,
  • it’s a live web system that undergoes multiple continuous changes,
  • we are dealing with a cloud-based system that already provides CD tools and practices,
  • configuring continuous delivery is essential to eliminate human errors at delivery,
  • the project requires a large and/or distributed development team.

 

That being said, continuous delivery practices provide significant benefits over continuous integration.

The benefits of continuous delivery

  1. Once configured, continuous delivery requires literally minimum time for delivery.
  2. Automated deployment allows to minimize human factor and thus eliminate errors.
  3. This is one of the best practices to automate IT infrastructure and improve the efficiency of the process.
  4. Continuous delivery provides better transparency in the development process since all the changes from team members are visible.

 

Tools to automate build and delivery

There’s a wide range of tools and services that help configure continuous delivery. Some of them are versatile and entail minimal learning curve, others are pretty complex and require serious experience.

Here are some of the systems that are worth mentioning in this regard.

  1. Cloud-based systems

Usually, when the application is hosted on a cloud-based platform, we can use its internal systems. For example, such platforms as Microsoft Azure and Amazon Web Services provide the internal tools to easily create a CI/CD pipeline and automate build and deployment.

  1. Specialized CI/CD tools

When the project is hosted on the vendor’s of client’s servers, we configure continuous integration and continuous delivery using specialized CI/CD tools. Often, these tools are a part of bigger systems widely used in software development. These are some of them:

  • Jenkins CI/CD tools by Atlassian
  • Gitlab CI

 

  1. Orchestration tools

These are the advanced devops tools to automate IT infrastructure and management. Often, these instruments require a great deal of learning and in return provide a wide range of features and perks. Access distribution, system monitoring and management and security are just some of them. These are some of the well-known orchestration tools:

  • Ansible
  • Puppet
  • SaltStack system
  • Chef

 

As you can see, both continuous integration and continuous delivery are valuable and can significantly increase the efficiency of a software development process. Each of the practices has its own scope of application, techniques and tools for adoption on a project. The trick is to choose the right practice for the right project and make sure this choice drives the efficiency and improves the quality of the final code, not vice versa.