Traditional CI tools often focus on concepts like steps and pipelines. These provide the basic building blocks that allow teams to craft complex workflows for various use cases.

However, these building blocks essentially mean most CI platforms are variations on a “thing doer”, a tool that just executes scripts in response to events.

Having spoken to a number of engineering teams from different companies, I’ve seen a clear pattern in the kinds of CI/CD pipelines that teams usually create. When teams construct their CI/CD pipelines, they will typically end up with very similar patterns based on a few key concepts. These concepts are builds, deployments, environments and tests.

Definitions

Builds

Builds are operations to transform source code into some kind of artifact that can be deployed. This could be a binary, a container image a tarball or even just a tag in a version control system.

A build may be combined with a deployment into a single step, but if you’re dealing with a lot of environments this could result in a performance hit.

Deployments

Deployments are operations that make an artifact available in an environment. This could involve applying yaml to Kubernetes, creating a VM in the cloud or uploading a few files via SFTP.

Deployments may create one resource or many instances, they could also operate on multiple environments in a single operation.

When dealing with many environments, it’s important to consider what happens when a deployment fails. Do you redeploy a previous build, do you leave things in a potentially bad state and alert a human?

Environments

Environments are the target for a deployment. They represent a single “location” where a build may be deployed. This could be a staging environment, a production environment, or even a production environment specific to a region or a single customer.

Most organizations start with a small number of environments, like staging+production or even just a single production environment. But as they grow, it’s likely that additional environments will be needed for different purposes. This can be most pronounced for B2B organizations that have varied compliance requirements and large customers with specific demands.

Tests

Tests are operations to verify a collection of source code, an artifact or an existing deployment behave as expected. There are many kinds of tests, which we won’t go into in detail here, but for the context of this article, it’s worth noting that some kinds of tests require an environment to run in, and some can run standalone.

A lot of tests will be intended to verify the result of a build or deployment, so can run as a part of those operations. Alternatively, I’ve seen some teams run tests continuously in a single environment to verify its integrity. You could also consider drift detection (checking for manual changes made outside of the pipeline) as another type of continuously run test.