CI/CD pipelines and tooling

CI/CD

In DevOps, a CI/CD pipeline needs to be implemented. CI/CD is the abbreviation of Continuous Integration / Continuous Deployment (sometimes Continuous Delivery is used instead). CI/CD is seen as the backbone to enable DevOps. It bridges, maybe even closes, the gap between development and operations by automating the building, packaging, testing, provisioning of infrastructure and deployment of applications. In addition to CI/CD, there are of course other aspects (pillars) that bridge the gap between Dev and Ops. See “High-performance IT delivery models“, for more explanation about DevOps. In this section an example CI/CD pipeline is explained, continuous everything is explained, the needed capabilities in a CI/CD pipeline are mentioned and examples of CI/CD tools are given. 

Example CI/CD pipeline 

A CI/CD pipeline is often tailor-made. In this section, a simplified model of the various stages within a CI/CD pipeline is used.

Our example CI/CD pipeline consists of the CI part (the build pipeline) and the CD part (the release pipeline), which contain the following stages:

• CI pipeline
  • Source Stage
    In most cases a pipeline run is triggered by a source code repository (such as GIT or SVN). A change in code triggers a notification to the CI/CD – orchestration – tool (such as Jenkins), which runs the corresponding pipeline. This includes, when applicable, merging all features from various branches from the repository.
  • Build Stage
    The source code (e.g. Java or C) is built to a deployable instance, packaged or containerized.
  • Team Test Stage
    In this stage, automated code review (static code analysis, with for example SonarQube) is carried out, as well as automated unit tests (with for instance JUnit, JMockit or Microsoft Unit Testing Framework) and integration tests (with for example Arquillian).
    All tests in the team test stage are the DevOps team’s responsibility.

• CD pipeline
  • Deploy for Business Test Stage
    When the runnable instance of the code has passed all code validations and predefined unit and integration tests, the package is deployed into a staging – test server – environment. Depending on the deployment strategy, there may be multiple deploy environments for different purposes. In this example we use one environment, which is called Business Test Stage.
  • Business Test Stage
    In this stage, test varieties such as user acceptance tests, performance tests, regression tests, production acceptance test (by operations), et cetera, are carried out either manually or automated (which are also referred to as dynamic application validations). (Automated tests are performed with, for instance, UFT, Xray, Selenium or Robot Framework.) And, as said, multiple environments may be required in order to support the different tests. All tests in the business test stage are the responsibility of the DevOps team, but they do require input from different business stakeholders that are outside the DevOps team.
  • Deploy for Production Stage
    When the application is validated and approved (i.e. accepted), the software can be deployed into the production environment. In respect to cloud-native software, the cloud infrastructure is provisioned together with the application.
  • Production, monitoring
    After deployment, the behavior of the system has to be continuously monitored during live operation (e.g. heartbeat checks and health checks), as well as the obtained information used to forecast the future behavior of the system and, if necessary, adaptive measures should be organized. With a fully automated release the monitoring tools and corresponding policies are automatic configured during deployment.

In every stage of the CI/CD pipeline, continuous monitoring (with tooling such as Dynatrace and New Relic) and the feedback from the monitoring are integrated. Any problem encountered in one of the stages will be – automatically – reported (with, for instance, ALM Octane or JIRA) and the CI/CD workflow will be stopped. DevOps teams have the practice to always have a successful CI/CD pipeline. DevOps team members will solve the problem and the process then reiterates if necessary.

Needed capabilities in a CI/CD pipeline

As mentioned at the start of this section, an automated CI/CD pipeline is seen as the backbone of DevOps. An automated pipeline enables:

• elimination of errors due to manual task execution.
• provisioning of standardized development feedback loops.
• enabling of fast product iterations

With a CI/CD pipeline, steps in the software delivery process are automated, such as initiating code builds, running automated tests, provisioning of infrastructure and deploying to a staging or production environment. When creating such a – fully – automated CI/CD pipeline, tools with specific capabilities are needed. Which tools with which capabilities you need, depend on the environment and chosen architecture of the CI/CD pipeline.

Below we provide a list of relevant capabilities per continuous activity:

• Continuous Integration
  • version control and configuration management for maintaining the different versions of the code.
  • compiler.
  • validation.
  • code review (automated and through “pull request”).
  • unit testing.
  • integration testing.
  • containerization (packaging).
• Continuous Delivery
  • configuration management.
  • user acceptance testing.
  • ready for deployment of the build application (container, package).
• Continuous Deployment
  • configuration management.
  • user acceptance testing.
  • deployment of the build application (container, package).
  • automated checks and validation for automated deployment approval.
• Continuous Monitoring
  • monitoring ensuring that the applications operate successfully.
  • alert management to get the right people’s attention when specific events occur in one of the DevOps activities.
  • analytics to be able to identify problems in the code and to perform root cause analysis.
  • team telemetry to understand the maturity of the team and how the team can improve.
  • live site telemetry to measure how the system runs, the platform behaves and log management.
  • cognitive monitoring to automate and improve IT operations by applying machine learning to the log data.
  • security monitoring to monitor security threats.
  • user telemetry to measure user sentiment and behavior.
• Continuous Quality & Testing
  • automated provisioning of test environments with test data.
  • automated test execution.
  • automated anomaly detection.
  • workflow supporting anomaly severity/priority assignment related to the risk.
  • AI and ML technologies to continuously and automatically optimize the test sets.
  • continuous visibility on quality status across the CI/CD pipeline.

CI/CD tooling

Many tools are available for supporting a CI/CD pipeline. Below you will find the CI/CD pipeline on which some frequently used tools are plotted.