The CI/CD pipeline is essentially a workflow that provides a pathway through which DevOps teams automate the software delivery process. In the absence of an automated pipeline, teams would have to configure their workflow to be performed manually, which is time-consuming and prone to error. The CI/CD pipeline removes manual errors, standardizes developers’ feedback loops and increases the speed of product iterations.
Predecessors to CI/CD include automated release automation (ARA) and automated release management (ARM), both of which fall under the category of work “release automation,” and represent new iterations of evolving automated processes and trends in this space.
There isn’t a standard methodology or implementation for a CI/CD pipeline, and each DevOps team will choose the tools and services they’ll use to build theirs, but a pipeline typically includes the following stages:
Source stage: Developers check out and locally work on application source codes stored in a central repository, such as GitHub. They then create a new branch for the feature or bug they want to fix, running tests on it locally in their development environment, before committing it back to the source repository.
Build stage: New code committed to the source repository triggers the build stage, in which the branch codes are gathered and compiled to build a runnable instance of the release. Developers can build and test their releases multiple times a day to detect errors in the code and receive alerts if a build fails, or about other issues so the team can implement a fix as soon as possible. Once the code is error-free, it moves onto the next stage.
Test stage: The build runs through several tests to validate the code and ensure it is acting as it should. Most commonly, these include unit tests, where the application is broken down into small units of code and tested individually, and user acceptance testing (UAT), in which people use the app to determine if the code requires more changes before it is deployed to production. Load, security and other continuous testing may be conducted at this stage.
Deployment stage: When the application is ready for production, there are many different deployment strategies from which to choose. The best choice depends on the type of application, how much overhauling it has undergone, the target environment and other factors. The following are modern deployment approaches for cloud applications.
- Rolling deployment: This method delivers the updated application incrementally until all targets have the updated version. Rolling deployments pose less downtime risk and are easy to roll back but require services to support both the new and old versions of the app.
- Blue-green deployment: In this method, developers run two versions of the app in parallel on separate infrastructures. The last stable version of the app is run in the production environment (blue) and the new version is run in a staging environment (green). The green version of the app is tested for functionality and performance, and as it passes, traffic is shifted from the blue environment to the green one, which becomes the new production environment. Blue-green deployments are fast and easy to implement but can be costly if the replicated production environment is particularly complex.
- Canary deployment: In this deployment model, developers release an application to a small subset of users who use it and provide feedback. Once the updated app is confirmed to be working correctly, it's rolled out to the remaining users. The strategy allows developers to test two versions of an app with real users side-by-side and allows updates and rollbacks without downtime.
At every stage of the pipeline, the development team receives alerts to errors so they can immediately address the issue. The code changes go through the pipeline again, so only error-free code is deployed to production.