Historically, developers have worked individually on different modules of an application and later integrated their code with the rest of the team’s manually. The occurrence of the next build could take days or even weeks to see if the new code would break anything. This isolated process often led to developers duplicating their code development efforts which formed their delivery models, and the effort to find bugs and fix them.
In the present era, the growth of Agile and the demand for fast and frequent solution delivery cycles is forcing us to replace the older development and delivery models with a more streamlined process.
Continuous integration and continuous delivery is an extension of Agile that focuses mainly on the tools and processes needed to integrate our work into the core code quickly, automate testing, and deliver continuous updates to enable a faster application development. The idea behind it is to create jobs that perform certain operations like building code, testing, deploying, and so on, automatically, rather than doing it manually.
Most teams work in multiple environments other than the production, such as development and testing, UAT environments, and continuous integration and continuous delivery ensures there is an automated way to push code changes to them and subsequently, to their delivery models.
Today, a lot of tools are available which support continuous integration and continuous delivery (CI/CD):
Continuous integration (CI) is a development practice that helps developers to check-in code into their code repository many times a day. Each checked-in code is then verified by an automated build process.
Continuous delivery (CD) is an approach in which teams ensure that every checked-in code is verified, tested, and releasable. Continuous delivery aims to make releases frequently through an automated process.
CI-CD Pipelines: The goal of the continuous integration and continuous delivery (CI/CD) pipeline is to enable teams to release frequent software updates into production to faster release cycles, lower costs, and reduce the risks associated with development. Once you have an automated process of CI and CD in place, the deployable unit path is called a pipeline.
Creating a CI/CD pipeline may be an overhead initially, but it is essentially a runnable specification of the steps that need to be performed in order to deliver a new version of the software. In the absence of an automated pipeline, engineers would still need to perform these repetitive steps manually, which reduces the productivity of the teams.
The following image shows different stages of a CI/CD pipeline:
Commit stage
A pipeline procedure is triggered when a code is committed to the repository hosted somewhere like GitHub. This notifies to the build system that something has changed.
Other common triggers include automatically scheduled or user-initiated workflows, as well as results of other pipelines.
Build stage
The Build stage combines the source code and its dependencies to build a deployable product in the docker container, ready to be shipped to our end users. Programs written in different languages need to be compiled first to create an environment-specific package in the docker container. Like for a web or an application server, the package in the docker container can be in the form of war, jar, or exe, whereas for a cloud environment, the software is typically deployed in a docker container, so the build stage creates a docker image to be deployed in the docker containers.
Test stage
In this phase, automated tests run to validate the correctness of the code and the behavior of the product. The test stage acts as a safeguard that prevents easily reproducible bugs from reaching the end-users. The responsibility of writing tests falls on the developers. Developers working in a TDD environment create unit test cases.
Depending on the size and complexity of the project, this phase can last from seconds to hours. Many large-scale projects run tests in multiple stages, starting with smoke tests, unit tests, and integration tests. Failure during the test stage exposes problems in code that developers didn’t foresee while writing the code.
Security Scan stage
Once testing is done, the product can go through the security scan stage. This stage is required to see early warning related to vulnerabilities and proper licensing to meet the security measures of different customers. Sometimes, vulnerable and poorly licensed products can fetch huge fines on product companies.
Some tools like Veracode, SonarQube, Splint, Coverity, etc. can easily be integrated with the build system to check any vulnerability in the product.
Deployment stage
Once the code has passed all predefined tests, we’re ready to deploy it. There are usually multiple deploy environments, for example, a “beta” or “staging” environment which is used internally by the product team to find the functionality breaks.
Advantages of the CI-CD pipeline:
- Faster release cycles
- Reduced risk of finding obvious bugs
- Lower costs by reducing the manual build to deployment processes
- Higher quality products as the CI-DC pipeline increases collaboration among teams to make a high-quality product
- Better business advantage to meet new market trends and user needs
Disadvantages:
- Need to spend a lot of time to find the perfect tool or combination of tools to create correct build and deployment scenario
- Need to spend a lot of time to automate the process
References:
