Continuous Integration, Continuous Delivery and Continuous Deployment

“Continuous” is one recurring word that can be heard in discussions about DevOps, where almost everything is continuous. Working with DevOps means continuous integration, continuous implementation or continuous software delivery. So how Continuous Integration, Continuous Delivery and Continuous Deployment differ from each other. Let’s take a closer look at the idea of continuity and why it is so central in DevOps practice.

Continuous Integration

Principle

I like to think of continuous integration in the wider sense that the aim is to integrate the whole system or solution as often and as early as possible. For me, continuous integration means that I want to integrate the whole system, while a continuous integration server could run on individual system modules. It also means that I want to carry out early integration tests and implement the system in the environment. It also means early “integration” of test data with the system in order to test as close to the final integration as possible.

In fact, for me, continuous integration means performing tests as accurately as possible and not leaving the integration test to the integration test at the end of the implementation’s life cycle. The smaller they are for the developer, the more often (several times a day) it can synchronize with the main line of code.

Practice

How does continuous integration work in practice? It’s probably the best known DevOps practice – it’s all about building/compiling software on a permanent basis. After each commit/merge process, the system starts the compilation process, unit tests and any static analysis tools used. There are also all other quality tests that can be automated. I would also add an automated implementation into one environment, so you can implement the system. This usually means that the entire code is merged into mainline or trunk before the start of the process. Working with mainline can be challenging, and concepts such as feature toggles are used to distinguish between functions that are ready for processing and functions that are still in progress. This leads to variants where continuous integration can only take place on specific branches of code.

This is not an ideal solution, but it is still better than the total lack of continuous integration.

Continuous Delivery vs Continuous Deployment

There is nothing more confusing than two different practices, which are called the same. So what is the difference between continuous delivery and continuous implementation? Look at the diagram below:

As you can see, the main practices are the same, and the difference lies in where to apply automation. In the case of Continuous Delivery, the goal is to automate the entire delivery life cycle up to the last environment before production, so that you can be ready for automatic implementation into production at any time. With Continuous Deployment, you can go one step further – in fact, you automatically deploy the solution in production. The real difference is whether you are dealing with an automatic or manual trigger. Of course, this practice requires really good tools throughout the supply chain: not all the aspects mentioned in the section on continuous integration are sufficient. It will also be necessary to have more sophisticated tools to test all the different aspects of the system (performance, operational readiness, etc.). Frankly speaking, I think it is often possible to find cases where greater human control is needed in terms of usability or other aspects that cannot be automated. However, the aim is to minimise them as much as possible.

Continuous testing

Last but not least, we come to the idea of continuous testing. For me, continuous testing means that a series of tests are carried out during system delivery. You should not wait until the last phases of the implementation to perform the test. It is recommended that you test the latest version of the software so that you can determine the actual quality scan. If you use Test-driven development (TDD), you can see the status of progress in real time. This technique is not very different from the others I have described above, but I like it because it diffuses testing from a distant phase to a current, continuous activity.

Summary

Thinking about software implementation we can talk about not continuous processes, which are in 0% automated and require manual work. The more we automate processes, the closer we get to 100% automation, which we can call Continuous Deployment.

I hope that the post was helpful for those for whom the deadlines were not fully understood. I will be happy to answer any questions you may have.