What Is CI/CD/CD

Sun, 04 Apr 2021 11:42:20 +0200

CI/CD/CD, sometimes shortened to CI/CD, is maybe one of the most common terms in the current software development community. Nearly every company, no matter how big, uses it. As a software engineer it’s thus close to impossible to avoid this term. But what exactly does this term stand for?

TL;DR: CI/CD/CD (Continuous Integration, Delivery and Deployment) is a set of practices and processes that aim to enforce a fast and reliable development process. This is achieved by automating as many steps as possible with predefined standards.

CI, CD and…. CD, again?

First of all, CI/CD/CD is not one term, but the abbreviation of three separate terms. Namely: Continuous Integration, Continuous Delivery and Continuous Deployment.

The concept of CI/CD/CD slowly evolved as a response to some of the problems that hinder the software development. Especially in bigger teams problems like:

Merging hell or the odd moment when multiple people working on one project, decide to merge their changes… And surprisingly afterwards it neither works nor has the number of bugs gone down.
Over complicated release schedules, that nearly always are impossible to stick to.
Varying quality of code
Ever changing requirements

tend to show up fairly quickly and often.

CI/CD/CD is a set of processes that aim to solve these problems, so that the overall process is smoother and more consistent. The three combinations stand therefore for the concept of achieving a fast, reliable and continuous software development process.

For this the entire process from coding to operating the product in a production environment is split into multiple stages. The goal is to then optimize these stages, by automating as many mundane and error-prone steps as possible. Acting as a guideline for the developers, each of the three terms from CI/CD/CD covers a set of stages. Each of these stages consists of a clear goal and best practices.

So, let’s take a look at these stages and their respective processes.

Continuous Integration

This is the foundation of the entire CI/CD/CD process suite. It precedes the following CD/CD processes and is nearly essential to them. And even through it would be possible to not implement it, I personally have never seen a company implement any part of the CD/CD processes, without implementing continuous integration in some way.

Continuous Integration itself is a set of processes, which aim to help developers maintain a stable, tested, high quality code base, without investing huge amounts of time. For this every code change runs sequentially through a predefined “pipeline” of automatized steps, where only posts that successfully pass through all the stages, end up in the final code base.

Build

Starting directly after the developer pushes his/her code changes, the build stage is triggered. Here the written code gets built into it’s executable/usable form via it’s compilers and build tools, like Maven or Gradle (for Java programs).

Goal / Success Condition: Successfully compiling/building the program without running into any fatal errors.

Additional Goals: Achieving certain key metrics like a maximum size or time to compile.

Test

After a code change is successfully build, the next logical step is to test the finished product on a multitude of levels.

Unit tests: This most basic level tests the individual functions and parts of the program.
Integration tests: These tests check the integration of the program in it’s part of a bigger system.
System tests: The automated system runs a test over the entire program system, to check for any unexpected side effects.

Each company handles the implementation of the varying levels differently. Some skip some tests, while others test each single level as thoroughly as possible.

Even through there exists no general best implementation strategy, a general consensus is to at least cover most of the code with unit tests. Whilst integration tests are normally at least run on a scheduled basis.

Another common practice is to include the code quality checks within the test stage. For this tools like SonarQube run static code analysis, checking for any violation of common practices.

Goal / Success Condition: Pass a certain percentage (optimally 100%) of the tests.

Additional Goals: Pass through static code analysis tools without any major violation.

Merge

As the simplest of the three continuous integration stages it’s only responsibility lies in applying the build and tested code changes to the current code base.

Goal / Success Condition: Apply code changes to the code base

Continuous Delivery

After running through the three stages of continuous integration the code changes are part of the existing code base. Depending on the size of the features that are in development, multiple code changes can accumulate, before a software release is planned.

As the releasing is no longer part of the continuous integration process, it was a manual process. Through the change in development methods and the shift from strictly planned waterfall models towards agile, iterative software development the manual release of accumulated code changes became a blocker for these fast agile methods.

As a solution to this problem, the already existing continuous integration process was extended by the new continuous delivery practices, resulting in the term CI/CD. This extends the set of automated stages by the stage Release.

Release

In the release stage the current code base is build into it’s usable form. Afterwards the system packages the results into a deliverable format, making it possible to deliver it to the customer at a moments notice.

Goal / Success Condition: Successfully building and packaging the product and saving it in some kind of repository.

Continuous Deployment

Whilst the goal of continuous delivery is to prepare a deliverable product, this still requires an actual person to go and set up the finished product.

Here continuous deployment, as the last part of the CI/CD/CD process, extends this process once more. It’s goal is to automatize the entire process from release to the deployment of the software for the client.

Deploy

This final stage of our CI/CD/CD process is the deploy stage. Within this stage our automation system takes the already released code and bundles it up. It then continues by pushing it into a production environment and installing it there.

A normal process for this is to either connect to the server directly via SSH or to use some external tool for the deployments like Octopus Deploy.

Goal / Success Condition: Having an up and running updated version of the application, which is accessible for the customers.

Wrapping it all up I hope this posts helps you understand the general principals behind the term CI/CD/CD and what each part of it is responsible for.

In the end it all boils down to the automation of mundane, manual steps to ensure a consistent, effective and fast working process for developers.

devops on Ole Gensch