What is CI/CD?

CI/CD is a set of best practices for DevOps and agile development. Continuous Integration (CI), Continuous Delivery (CD) and Continuous Deployment (CD) define a culture, as well as operating principles and practices, that teams use to deliver new features and bug fixes more frequently and reliably by automating integration and delivery. CI/CD lets the teams focus on business requirements while ensuring code quality and other standards.

Continuous Integration

Continuous Integration is a method and a set of practices that drive teams to implement small changes and frequently check them into a version control repository. Developing a modern application requires a variety of platforms and tools, therefore development teams need a mechanism to integrate and validate changes in a consistent way. Continuous Integration help teams achieve this goal. It establishes an automated way to build, package, and test their applications.

Continuous Delivery

image alt Continuous Delivery starts where Continuous Integration ends. It automates the delivery of applications to selected environments, including Development, Test, Pre-Production and Production. Continuous Delivery standardizes how a package is being delivered to an environment while providing security and approval gates.

Continuous Deployment

A mature team with a robust CI/CD pipeline can also implement Continuous Deployment, where application changes runs through CI/CD pipeline, the ones passing builds and automated tests being deployed directly to selected environments, even to Production. Continuous Deployment isn't optimal for every application though. It is highly recommended for lower environments, like development and test, but applying it to pre-production and production has to be agreed with the customer and proper approval gates must be implemented.

How CI/CD improves team collaboration and code quality

CI/CD is a development philosophy backed by processes and automation. Members of teams, which are practicing CI/CD, commit their code changes frequently, at least once a day. The reason of this principle is that it's easier to identify defects and quality issues on smaller code differentials than on larger ones. In addition, it is less likely that more than one developer will edit the same code which would require merge when committing. Although checking in code is done frequently, teams work on features and fixes on shorter and longer time frames. To address these needs, teams use different techniques to control what features are ready for Production. These techniques include implementing branching strategy, code review process, automated testing, feature flags etc.

Automated builds and testing

In an automated build process, all components are packaged together. However the CI build does not only package the components, but also automatically executes unit tests, integration test and other types of tests. Automated testing provides quick feedback to developers that their changes did not break anything. Builds can be triggered on demand, by code commit or on predefined schedule. A best practice is to ensure that each commit is validated by a build before it can be added to the codebase. This means that validation has to be quick, so at this stage the build ensures only that the code can be built and that no unit tests are broken by the change. Other types of tests, which are required for a full delivery - such as integration, UI and load testing - are often integrated into CD pipeline and executed after a package is delivered into its target environment.

Automated testing helps development teams with quality assurance. Ideally these tests, beside other aforementioned types of tests, include functional tests as well, which can be aggregated into a regression test set for the whole application. A best practice is to enable and require team members to run all unit tests and at least a relevant subset of regression tests in their local environments before every commit. This step ensures that only well tested code changes are committed.

Stages of CI/CD pipelines

A typical CI/CD pipeline has build, test and deploy stages. Below activities could be included at different stages, list is not exhaustive:

  • Pulling and building the code
  • Automated security, quality and compliance checks and approval gates
  • Execute "infrastructure as code (IaC)" steps to set up required landscape
  • Move code to target environment
  • Configure components for target environment
  • Execute automated tests and rollback environments in case of failure