CONTINUOUS INTEGRATION VS. CONTINUOUS DELIVERY VS. CONTINUOUS DEPLOYMENT

But software development field does not have one-size-fits-all solutions. Different software development methodologies work better in different scenarios. For example, the waterfall method works well for a project with clearly defined requirements, while the agile approach works efficiently for projects that have changing needs.

Though you may come across different procedures for software development, DevOps is one of the methodologies that aims to speed up delivery and accuracy. It provides developers the tools to deliver more reliable products with fewer bugs and implement continuous improvements.

Speaking of continuous improvements, you might have heard about the terms: continuous integration, continuous delivery and continuous deployment. Though the differences between the three seem confusing, you should know about some of the essential distinctions.

Continuous Integration, Continuous Delivery and Continuous Deployment are like vectors with the same direction but different magnitude. All three terms aim to make the software development and release process more robust and quicker.

We shall discuss the following topics in the article:

• What is Continuous Integration?
• What is meant by Continuous Delivery?
• What is Continuous Deployment?
• What is the difference between Continuous Integration, Continuous Delivery and Continuous Deployment?

What is Continuous Integration with example?

Continuous Integration is a development practice that requires developers to integrate code into a mainline as frequently as possible, at least once a day. An automated build that compiles the code then verifies each check-in and runs the set of automated tests against it so that teams can quickly detect problems.

Let’s understand with a simple example.

First of all, we will consider an old approach that existed before the DevOps was introduced. For example, there is a team of 30-50 developers, out of which two developers, John and Bob, are working on their features. They plan to get their features to work against the codebase. After a couple of weeks or months, they will be integrating or merging their work. However, it can lead to a merge conflict if John changes a line of code or Bob deletes a line of code.

This approach might bring up new bugs. We have just talked about two developers working on the same code. But what if many developers (say more than 10 developers) work on the same application that can have thousands or millions of files and features.

That is what arises the need for the new methodology, i.e., DevOps. Now, let’s understand the above situation from the perspective of Continuous Integration.

John writes his code. He submits the code in the source code as soon as he has something that works a little bit, even if the feature is not done yet. Another developer, Bob, pulls down the same code before he starts working. John always submits his code whenever he has a working code. Bob makes the changes in John’s code by pulling it from Source Control and can add or delete a line of code.

John comes back and he is working on another part of the feature and may grab Bob’s code.  Now, they are working on the same thing and, at the same time with minimal conflict. In case, they come across any conflict, it’s all the code that they might have worked on the last day. They can interact with each other and reconcile issues quickly.

But there could be a lot of people constantly checking in code into the codebase. Continuous integration may lead to constant broken problems. However, it can be avoided by enabling automation to keep an eye on the code. Whenever any change happens in the code, it is verified by an automated build and automated tests.

One of the significant benefits of continuous integration is to detect errors quickly and find them more easily. Continuous integration has become one of the best practices for software development.

It is a coding philosophy and set of practices that frequently allow development teams to implement small changes and check-in code to version repositories. The goal of Continuous Integration is to establish an automated way to develop, package and test applications. Due to consistency in the integration process, teams can commit code changes more often, resulting in better collaboration and software quality.

To implement continuous integration, developers must know that:

• Tasks should be classified as small as possible in the planning stage because the code should be programmed and integrated into the mainline as frequently as possible, at least once a day.
• Automated tests should be run for each new feature, bug fix or improvement to ensure that a change does not break any other part.

A smooth continuous integration process makes sure that the mainline is always in a deployable state. Continuous integration and other Extreme Programming Practices, including automated tests, test-driven development, pair programming, simple design, and refactoring, can contribute to the software program’s quality. If the team of developers does not care about these methods, you cannot ensure that it works as expected. You cannot have an automated deployment flow if you don’t know whether the code being delivered works or not. That is why Continuous Integration is mainly required for Continuous Delivery and Continuous Deployment.

What is meant by Continuous Delivery?

Continuous Delivery is the process of getting changes of all types, including configuration changes, bug fixes, experiments and new features into production or into the hands of users in a sustainable way. When a team of developers implements continuous delivery, the mainline is in a deployable state and anyone can deploy it to the production anytime with the click of a button. When the button is clicked, an automated pipeline gets triggered. The significant element to achieve continuous delivery is automation.

As you can deploy to production anytime, the question is, when is the right time to move into production? The answer may depend on your business requirements. Still, the fact is that if you want the benefits of continuous delivery, you need to deploy to production as early as possible. Deploying early can ensure that released small batches are easy to troubleshoot in case of any issue.

It is aimed at automating the entire software release process. In Continuous Delivery, Continuous Integration is done and a release is prepared and tracked automatically to move into the production.

The continuous delivery process is not fully autonomous; it typically includes at least one manual step to initiate and approve a deploy to production. In complicated systems with multiple dependencies, the continuous delivery pipeline may require additional steps that are either automatic or manual.

David Farley and Jez Humble mentioned in their book, “Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation” that the developers should consider the following checklist while submitting the code:

1. Before submitting code changes, check if a build is currently in the “successful” status. If it is not, you should help in fixing a build before you submit a new code.
2. If the build status is currently “successful”, you need to rebase your workspace according to this configuration.
3. Build and test locally so that the update does not break any functionality.
4. If the build runs successfully on the local, check-in new code.
5. Allow Continuous Integration to complete with new changes.
6. If the build fails, halt and fix it on your system. Go back to step 3.
7. If build gets failed, continue to work on another item in the pipeline.

Both continuous integration and continuous delivery require continuous testing because the aim is to deliver quality code and applications to users.

What is Continuous Deployment?

Continuous Deployment is a step up from Continuous Delivery where every change in the source code is deployed to production automatically without requiring explicit approval from a developer. A developer’s role usually ends at checking a pull request from a teammate and merging it to the master branch. Continuous Integration/Continuous Delivery takes it from there by executing all automated tests and deploying the code to production while keeping the team updated about the outcome of every event.

In continuous delivery, every change pushed to the master branch is ready to be deployed for production, but it still requires human involvement. However, in continuous deployment, the deployment to production is triggered automatically for every change passed by the test suite.

What is the difference between Continuous Integration, Continuous Delivery and Continous Deployment?

Source:dZone

As pointed out earlier, Continuous Deployment is related to Continuous Integration and implies keeping an application deployable at all times and or even releasing it into production automatically if the latest version passes automated tests. If you want to release your product quickly, you should automate the entire workflow, not only testing.

However, continuous delivery involves manual intervention after the acceptance testing is done to move the build to the production stage. Once a developer or a team of developers verify the build after running automated tests until acceptance testing, they can pass automated tests into a test or production environment.

Our team of DevOps engineers has a good understanding of the above procedures and understands when to implement any of these technology based on the project requirements. If you are looking to have in-depth know-how of continuous integration, continuous delivery and continuous deployment, consult our DevOps experts.