In this article, I want to take a closer look at the various change practices that exist in programming today. So let`s talk about what Continuous Integration, Delivery and Deployment are, how they differ and why these approaches are so important.
What is Continuous Integration, Delivery and Deployment
In the past, developers could spend a lot of time working alone and then merge their changes into the master branch after they were done. This resulted in bugs accumulating over a long period without resolution, and the integration of code changes was difficult and time-consuming.
These considerations made it more difficult to provide updates to customers promptly. Therefore, new approaches to change, collaboration and division of "responsibilities" for teams began to emerge.
Continuous Integration, Delivery and Deployment are processes that facilitate the introduction of changes to the application for their rapid deployment to the environment (prod, staging, dev and others). Most often, this is implemented by creating pipelines that automate certain repetitive actions.
The diagram shows which processes belong to each approach. And although the approaches are depicted together, most often, from Continuous Delivery and Deployment, one is chosen that suits the internal development processes the most. So let's talk about these approaches and consider each of them in more detail.
Continuous Integration
Continuous Integration is the process of combining code changes from several developers into one joint project, which should be performed as often as possible. In general, this task is entrusted to the version control system (git). And why is it necessary?
Currently, most repositories are set up so that when we make any changes to the version control system, we run a chain of processes that should check the basic functionality of the code - testing, formatting rules, compiling the latest version of the code to check whether the new changes are free of errors, that will "fail" a potential build.
So all these processes are aimed at finding your bugs earlier, improving the quality of the final product and reducing the time of verification and release of new functionality. And while bugs cannot be avoided, Continuous Integration can help by identifying and fixing them. This is the main reason why businesses today are moving away from legacy approaches to CI.
Continuous Delivery & Deployment
Having considered the first step of automation processes, let's move to the stage when we already have tested, high-quality functionality that should be released. And this is where Continuous Delivery comes into play. What is this magic phrase?
Essentially, it's an automated rollout of the latest version of a product to Production and other environments. But before that, the code must pass automated Unit-, Integration- and System-testing, which are carried out at the integration stage.
So, by combining the two processes above, we can get the tested functionality immediately deployed in the environment using a one-click pipeline. Of course, the decision to deploy a new release must be made by a person, but the system does the preparation.
Consider another process called Continuous Deployment. This is the next step in deploying changes to the environment. In its essence, continuous deployment is a practice in development, when any changes get into the production environment as soon as possible.
The goal of this process is only one thing: to release the changes made by developers, to deliver them to end users as often and as quickly as possible. That is, when a new release is released, the pipeline picks it up, verifies that all checks are completed, and creates a build that will be deployed immediately to Production.
Please note that a person is not involved in this process at all, and only if the tests "fail", the code will not be deployed in the environment.
Difference between Continuous Delivery & Deployment
Often these two processes are put on the same level and naively say that they are synonymous concepts. In fact, there are significant differences between the two that your keen eye might have already noticed.
In short, Continuous Delivery is aimed at maintaining the code in a state where it is always ready to be released and deployed to Production, but only at the direction of the person controlling this process.
In contrast, Continuous Deployment shortens this process and deploys changes to the environment at the first opportunity, when test plans are successful.
Which of these plans is better? Everything depends on the needs of a specific product: if you need to quickly deliver changes to the end user and shorten the so-called feedback loop: Deployment is the best fit here; if the code implementation process for end users must be manually controlled and verified before release: Delivery is your choice.
But certain products require one or another approach. For example, for web platforms or applications, it will make sense to go through Quality Assurance before getting into the hands of end users, so the Continuous Delivery approach will be used here, but for monolithic applications or certain databases, the best option will be Deployment.
But Continuous Deployment and Continuous Delivery have enough in common. Both approaches depend on project infrastructure and monitoring systems to ensure product support and detect most bugs before certain changes are released.
| Continuous Delivery | Continuous Deployment |
|---|---|
| An approach where code changes must be verified by a human in order to be released to Production. | An approach that adds code changes to release in Production automatically. |
| 1. more stable and controlled releases. 2. releases are small in scope of changes in them. 3. releases occur frequently. 4. quick response to bugs. | 1. automation of the entire process of implementing changes. 2. creating a fully automated CI/CD pipeline. 3. changes are immediately available to end users. |
| Useful for companies that want to frequently update the application with new functionality. | Useful for organizations that want to update the application as often as possible. |
| Has no specific environment requirements and can be implemented in almost any development environment. | The approach will be most appropriate for the following factors: 1. the project must have comprehensive automated testing to be sure of the quality of the release. 2. the approach is partially implemented: the release is made for a limited number of users (beta) and after feedback is collected, the release is made to Production manually. 3. the quality of each release does not matter (for example, if we are developing something for internal use). |
So, with the definition of these two processes, we figured it out, now we will consider an example. Let's remember that in the section on Continuous Integration, we have already received a ready-made build that has undergone automated testing.
Conclusion
So we looked at the three main possible stages of deployment of changes and functionality under development. Let's put everything together: Continuous Integration is a process of automated testing and verification, which allows you to start testing certain parts or the entire application for each change in the code.
Continuous Delivery and Deployment is the process of getting tested functionality, bug fixes, etc. into a production environment.
We also saw the main difference between the Continuous Delivery and Deployment approaches - the first one focuses on ensuring that the functionality is always ready for release and waiting for the team to deploy it in the environment. And the second immediately deploys the build with changes immediately after passing the tests in automatic mode.
All these approaches are aimed at improving the process of implementing changes to the application and deploying releases in the environment. Each of them is suitable for certain needs and only you decide which of the approaches will be used by you.
Top comments (0)