In the process of software development, the idea of continuous integration, continuous delivery and continuous deployment are inseparable from each other. Using CI/CD pipelines is on the list of best practices in DevOps work, but what exactly such a pipeline stands for and what are the processes of continuous integration and continuous delivery separately?
What’s the difference between continuous integration, continuous delivery and continuous deployment?
You can find definitions of continuous integration and continuous delivery in this article. In very simple words - CI means running constant code integration tests to make sure they are compatible with the root branch of the application and do not cause any regressions. CD is a programming practice which delivers code to the environment as soon as feature development is finished. Thus the new code parts are deployed right after passing tests. Besides, both continuous integration and deployment also cover actions like automated testing, analytics or reporting errors.
The whole process should be done automatically, but in situations where the organization isn’t ready for full automation or there is no technical possibility, a so-called manual gateway is also acceptable.
These three elements are strongly connected and all together belong to main responsibilities of DevOps engineers. Continuous delivery will be useless without properly working continuous integration and automated testing of all levels. And speaking about tests - continuous testing is also an important part of a CI/CD pipeline and general application development. It’s always best to test the final version of code or try Test-driven development (TDD) in which the developer writes a test for functionalities that don’t exist yet.
The essence of CI/CD
The CI/CD process assumes sending new code changes to the repository as often as possible. Most development teams do it at least once a day. In case of errors, it’s much easier to analyze and correct a small part of the code instead of one big package. What’s more, short delivery reduces the possibility of changes in one file by two or more developers (which later requires resolving conflicts by merging different parts of a code). It’s very useful especially in the case of advanced projects with a few levels of verification and a few environments. Continuous delivery creates an automation of sending code changes to these environments.
Below you can see examples of steps included in a typical CI/CD pipeline:
- Downloading a code from repository and starting a build
- Transfer of a code to one of the chosen environments
- Environments variables management and configurations
- Moving application components to proper services (e.g. WEB, API, database)
- Continuous Tests and undoing changes in case of errors
- Doing backups
- Synchronization of data
- Reports of results
- Providing log data and alerts on the state of the delivery.
Of course these are only examples of CI/CD actions. There are also many tools dedicated to creating and managing a pipeline (or pipelines). You can find out more about them here.
Who profits the CI/CD process?
The answer for the question above might be obvious, but everybody. We can say that every stage of the pipeline is for a particular group - continuous integration makes development teams work easier and faster. Continuous delivery is targeted to business users (customers), who can quickly test and experience the application, give their feedback to developers and expect changes even within a few hours (in case of waterfall methodology mentioned here they would have to wait even a few weeks). Finally the continuous deployment process benefits all stakeholders, like investors, but also the application users who can enjoy new features and updates in a short period of time.
Why use CI/CD pipeline?
Although creating a CI/CD pipeline requires a lot of knowledge and careful work (one mistake can easily disintegrate the whole process!) with the help of specific tools, in the case of advanced, extensive applications the benefits are priceless. Besides the tasks mentioned above, the process of continuous delivery includes other necessary mechanisms, like doing the SQL queries, sending notifications and requests to the HTTP server or even restarting some services. In the end, the teams keep better control over code changes, which leads to the higher quality, less bugs, and finally to better cooperation and fast delivery of finished applications.