Continuous Integration, Delivery, and Deployment Explained

Before DevOps, we had these traditional engineering practices where different teams had their own duties in the software development and release cycle.

Most of the process in the software release pipeline was manual and the communication between teams created a lot of friction in the software release process.

With the advent of DevOps,  the siloed teams started working together, a lot of processes got automated using devops tools and the software release time is reduced to a great extent when compared to traditional models.

Moreover, continuous feedback in DevOps methodology helps organizations to innovate, fix bugs, and change functionality in very little time.

Understanding Continuous Integration, Delivery, and Deployment

Now let’s look into the main pillars of application lifecycle management (ALM).

1. Continuous Integration
2. Continuous Delivery
3. Continuous Deployment.

1. Continuous Integration

If you take the traditional software development model, the integration of code from different developers takes days to weeks to even months.

So what does this integration really mean?

Normally for developing an application, multiple developers work on a single code repository. Normally this code repository will be a remote one and every developer keeps a local copy.

So when we say integrate, all these developers will push their local code to the remote common repository.

Since all the developers were working separately, when the integration happens, there will be unexpected errors and failures. Then the teams would start working on identifying the problems and will try to fix them.

Then came the concept of extreme programming followed by continuous integration.

Continuous integration is a practice where you integrate the code very often to find the issues in the earlier stages. In continuous integration, every developer commit goes through the following.

1. Static code analysis
2. Unit tests and
3. Functional tests.
4. Deployment
5. Integration tests.

By following this, you get continuous feedback from relevant stockholders and teams associated with the project.

As the CI process is automated, the teams will get notified in minutes after the developer commit if anything in the system fails.

If anything goes wrong, fixing that would be the first priority rather than continue working on the application.

Recommended Book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

2. Continuous Delivery

Continuous Delivery is the confidence that you have in the code which passed all the tests for deploying it to production.

3. Continuous Deployment

Continuous deployment is the same as continuous delivery with the only difference of no manual intervention.

This means, in continuous delivery, there will be decision-makers for moving the code to production.

In continuous deployment, once the code passes all the tests, it will be automatically moved to production without any manual intervention.

So if a developer commit does not have any issues, it directly goes to production.

Difference between Continuous Delivery and Deployment

The key difference between continuous delivery and continuous deployment is shown below.

As explained before, in the software delivery pipeline, if there is no manual intervention and everything is automated, it is Continuous deployment.