Kamil Porembiński
When beginning the topic of deployment automation, it is important to start with the key term DevOps. In this field, we often hear that any change or activity is continuous. DevOps work is said to be Continuous Integration, Continuous Deployment or Continuous Delivery. What are the differences between the formulations in question? Let’s check and dispel any doubts.
The whole process called continuous integration can be put in several ways. In a broader sense, the goal is to integrate the entire system or solutions to integrate environments as often and as early as possible. In other words, continuous integration means that we want to integrate the entire system, while a continuous integration server could run on individual system modules. It sounds complicated, but it’s nothing more than running integration tests to implement the system into a specific environment. It also means early “integration” of test data into the system in order to test as close as possible to the final integration.
For me, Continuous Integration is the ability to do thorough testing and not leave integration to integration testing at the end of the implementation lifecycle. The smaller the tasks are for the developer, the more often (even several times a day) he can synchronize with the main line of code.
How does continuous integration work in practice?
Probably most of you are very familiar with the answer to this question, as it is the most well-known of the DevOps practices, which involves the permanent compilation (construction) of software. After each commit/merge process, the system runs the compilation process, unit tests and any static analysis tools used. All other quality-related tests are also carried out, where automation is the key word. I would also add automated implementation into a single environment, so you can deploy the system. This usually means that all code is merged into the mainline or trunk before the process begins. Working with mainline can be challenging, and concepts such as feature toggle are used to distinguish between features that are ready for processing and features that are still in progress. This leads to a number of variants in which continuous integration can only take place on specific branches of the code.
Is this an ideal solution? Don’t. However, it is still much better than a complete lack of continuous integration.
Two practices that, as it turns out, are often confused because the abbreviations sound the same [note: in English, the abbreviation for both terms is CD]. Then what is the difference between continuous delivery and continuous deployment?
The diagram below perfectly identifies one but significant difference. Take a look:
As you may have noticed, the main practices are the same. The apparent difference is where to apply the automation.
In Continuous Delivery, the goal is to automate the entire delivery lifecycle, all the way down to the last pre-production environment, so that an automated deployment of the designed code to any production environment (e.g., an application) can be carried out at any time.
The Continuous Deployment process skips one step. You deploy the automatically tested solution directly to production. The actual difference is whether we are dealing with an automatic or manual trigger. Of course, such a practice requires really well-chosen tools throughout the supply chain. All the aspects mentioned in the section on continuous integration are not enough. It will also be necessary to have more sophisticated tools to test all the different aspects of the system (performance or readiness).
I think there is a chance to hit cases where more control or human intervention will be necessary. Especially in terms of usability or other elements that cannot be automated, and writing tests is essential. However, the goal of automatic deployment is to minimize manual actions as much as possible.
Continuous testing is nothing more than a series of tests of a finished application or other environment. However, do not wait until the final phases of implementation to perform the test. According to many documentations, it is recommended to perform tests on the latest version of the software, so you can determine its actual quality scan. Common techniques used are Test-driven development (TDD), where you see the status of the latest version in real time. This technique is not very different from the others I described above. Its advantage is that it captures the diffusion of testing from a distant phase to a current, ongoing activity.
Thinking about software implementation, we can talk about not continuous processes, which are not in any hundredth degree automated and require only manual work. Full automation (called Continuous Deployment) saves time, but also money. In addition, well-built processes enable the introduction of good practices throughout the organization, which speeds up overall project implementation.
Do you have questions? Bold. We will talk about automating the entire deployment process in your company.
