CI and CD are two terms that are increasingly used in the software development process. CI stands for Continuous Integration, a fundamental practice where developers often combine code changes by placing it in a central source code repository where automatic compilations and tests of the IT system being built are run. CD, on the other hand, can mean continuous delivery or continuous deployment. Later in the article, an attempt will be made to explain this topic.

Continuous integration

Development teams using continuous integration merge their changes back into the main branch of the source code repository as often as possible. Changes made by a given developer are verified by running a build and automated tests. This avoids the integration problems that can happen when the system code is merged very late – for example when creating an installation version of the system.

Continuous Integration puts a strong emphasis on test automation to ensure that the application has no bugs each time new changes to the system’s source code are integrated into the main branch of the code repository.

A separate article has been devoted to the topic of continuous integration:

Read also: What is Continuous Integration?

Continuous delivery

Continuous Delivery is an extension of Continuous Integration as it automatically deploys all code changes to the test and / or production environment after the build stage.

This means that in addition to automatic testing, the process of releasing new software versions has also been automated. Thanks to this, it is possible to implement a new version of the application at any time – by starting the process of installing or updating the system.

Due to the fact that the continuous delivery process creates new system releases, once the continuous integration process is successful, it is possible to make unfettered decisions about the frequency of releasing new system releases. You can choose to release new versions daily, weekly, biweekly, or as required by your business requirements. To experience the full benefits of Continuous Delivery, implement processes in your software development teams as early as possible. Thanks to this, already at the initial stages of building the system, we can make sure that by releasing small batches of new functionalities, we can easily solve problems / errors as they appear.

Continuous deployment

Continuous Deployment goes one step further than Continuous Delivery. Thanks to this practice, each change that goes through all stages of the software production process is made available to customers. There is no human intervention during the process of releasing a new version of the software, and only a failed test prevents the implementation of the new change in the production environment.

Continuous rollout is a great way to speed up customer feedback and relieve the workload of the production team, as there is no specific day when software production actually stops to focus on the correct release of the new software version. Developers can focus on software development and see their work being implemented at the client’s site in a very short time – after the new functionality has been placed in the main source code repository of the system.

CI / CD relationship

The relationship between CI and CD is as follows – continuous integration is part of both continuous delivery and continuous deployment. Continuous deployment is like continuous delivery, except that releases occur automatically.

What are the benefits of using CI / CD?

The differences between continuous integration, continuous delivery and continuous deployment are explained. You should also analyze the reasons why you should use them. The implementation of each practice involves obvious costs, but there are certainly also immeasurably greater benefits that come from using CI / CD.

Continuous integration – costs and benefits

Cost:

• the development team will have to develop automated tests for each new feature, change or bug fix,
• you must provide a continuous integration server that can monitor the main source code repository and automatically run tests for each new change that the developer places in that repository,
• developers need to merge their changes as often as possible, at least once a day.

Benefits:

• fewer errors are sent to production as regression errors are recorded early by automated testing,
• building new versions of the system is easy as all integration problems have been solved earlier,
• less context switching as developers are warned as soon as they break a build and can work on fixing it before moving on to another task,
• testing costs are drastically reduced – the CI server can run hundreds of tests within seconds,
• QA team spends less time testing and can focus on making further improvements to automating the QC process.

Continuous delivery – costs and benefits

Cost:

• you need a solid foundation for continuous integration, the test suite must cover a significant amount of source code,
• the delivery process must be automated. The trigger is still manual, but once deployment begins, there should be no need for human intervention,
• the team will most likely need to adopt feature flags so that incomplete features do not affect customers in the production environment.

Benefits:

• simplify software deployment – the production team doesn’t have to spend days getting ready to release a new software version,
• the possibility of more frequent release of the version, thus speeding up the feedback loop with customers,
• the fears of deciding to make small changes are much lower, encouraging faster iterations.

Continuous deployment – costs and benefits

Cost:

• the quality of the testing process must be of a very high standard – the quality of the test suite will determine the quality of new software releases,
• the documentation process will have to keep pace with the pace of implementation,
• Feature flags become an integral part of the process of issuing significant changes to ensure coordination with other departments (support, marketing, PR, etc.).

Benefits:

• development becomes faster as there is no need to hold development for releases. Deployment pipelines are automatically triggered for every change,
• Releases are less risky and easier to fix in the event of problems when small batches of changes are implemented,
• customers see a steady stream of improvements, and quality increases every day – not every month, quarter or year.

How to move to continuous deployment

In the event that work begins on a new IT system that does not yet have users, the implementation of new functionalities in the production environment may be easy. In this case, you can even start by automating the implementations and launch the alpha version for production. Then extend the operation of the automated tests while ensuring that the coverage of the tested code is increased when the application is compiled.

Once ready for user deployment, the continuous deployment process reaches maturity where all new changes will be tested before being automatically rolled into production.

On the other hand, in the case of an application in which clients already work, development work should be slowed down in favor of building the process, starting from continuous integration and continuous delivery. A good starting point is to implement basic unit tests that are executed automatically, without having to focus on performing complex end-to-end tests. Instead, try to automate the deployment process as soon as possible and move to the stage where deployments in pre-production environments are done automatically. The reason is that with automated deployments, it is possible to focus your energy on improving tests rather than stopping the software development process periodically to coordinate the release of new IT system versions.

Once the daily software release process begins, then you can take a closer look at the continuous deployment process. Make sure that the rest of the organization is prepared for this approach as well. Documentation, support, marketing – they will have to adapt to the new approach in delivering new software versions. It’s important not to miss any significant changes that could impact your customers.

CD – automation, quality, future

As you can see, thanks to the implementation of the CD, it is possible to achieve a new quality in software development. Automation in this area ensures that the production process does not jam and runs like a well-oiled machine. At the same time, focusing on the quality of the produced software brings real benefits to end customers satisfied with the use of newer and newer versions of the application free from bugs and errors. And for development teams, the CD gives the opportunity to free themselves from recurring errors and problems related to publishing and sharing software. And last but not least, the CD gives you the joy of creating new, innovative solutions.