What is CI/CD?

By Richard Lander, CTO | April 26, 2024

CI/CD stands for "Continuous Integration" and "Continuous Delivery."

These are actually two very distinct concerns. Mashing them into a single term was largely a product of using a common tool to manage both. Jenkins was, for a long time, the tool of choice for CI/CD. You can think of Jenkins as a thing-doer. If you have a set of automations (things) that you need to execute (do), Jenkins provides a way to configure that.

Because these are very distinct concerns, let's look at each individually.

Continuous Integration

Continuous Integration (CI) refers to the automation used to release a version of your software. Once code has been written and is considered ready for release, CI processes perform things like:

• Linting to make sure submitted code conforms to style guides and accepted formatting rules.
• Testing to ensure no bugs have been introduced.
• Building processes to produce binary and/or container image assets.
• Pushing build assets to a repository so they're available for delivery.

There are often many other supporting operations included in CI pipelines, but they generally boil down to releasing versions of software from its source code.

While Jenkins has been used a lot in the past, tools like GitHub Actions and Circle CI have become very popular in more recent times. They each promote themselves as CI/CD tools, but using them for more than CI is ill advised unless you manage pretty simple systems.

Developers working on a project usually manage the CI configuration because it is so closely related to the code being written. It is usually little trouble to maintain once set up, and naturally evolves with the code itself.

Continuous Delivery

Continuous Delivery (CD) is concerned with delivering applications to their runtime environment once they’ve been released. This includes new deployments as well as updates to existing deployments. Because deployed apps have dependencies, it also includes managing the following concerns:

• Compute infrastructure has to exist and be configured to support the app.
• Runtime environments such as Kubernetes need to be provisioned and configured to support the app.
• Managed services that are a part of the app stack, such as managed databases.
• Support services that provide important utility functions to support the app. These include things like network routing, TLS termination, observability, secret management and many others.

If any of these pieces are missing or misconfigured, the delivered app won't run as intended. Because this a broad set of concerns, many different tools are often involved which can incur significant challenges. The more complex the application architecture and dependencies, the more complicated the delivery process is.

Specialized CD systems have arisen to serve this complex need. In cloud native environments, ArgoCD and FluxCD are good examples. These are called "GitOps" systems. For more detail on GitOps in particular, see our blog post: What is GitOps? They are concerned with managing Kubernetes resources using integrations with tools such as Helm and Kustomize. So if you have compute infrastructure or cloud provider managed services defined in Terraform configs, you have a bridge to cross. You can migrate to using a Kubernetes-based controller such as the AWS Controllers for Kubernetes, but you still have orchestration concerns to connect your app to the deployed infrastructure and services.

There is considerable domain expertise required to manage software delivery. It is unreasonable to expect developers to wrangle CD along with their development responsibilities. Therefore, DevOps and platform engineering teams are usually responsible for delivery systems in large organizations. In smaller organizations, some of this may fall on developers.

Separation of Concerns

Due to the separation of responsibilities and the different tool sets now commonly employed to manage modern software, CI/CD has largely been separated. They are no longer managed by the same system in most organizations, and a division of labor between the concerns has emerged.

This has led to improvements in CD, but there is still work to be done. The increasing sophistication of cloud native software, the proliferation of microservices, and the diversity of dependencies that arise has raised the bar on what is expected from CD.

Application Orchestration

At Qleet we're redefining software delivery. Application orchestration involves using software in an extensible control plane to manage app delivery along with all of the app's dependencies. This is an alternative to the pipeline-based CD systems the industry has been using and is critical to reducing the engineering overhead of software delivery.

Threeport

Threeport is an application orchestrator. It delivers your application to its runtime environment but does something very important in addition to that: Threeport provisions your app's dependencies and configures the system so they are available when your app starts. The dependencies managed by Threeport include:

• Cloud provider infrastructure.
• Kubernetes runtime environments.
• Managed service dependencies that are a part of your app stack, such as managed databases.
• Support services that are installed on Kubernetes to provide essential services, such as network ingress, TLS termination, DNS record management, observability and secrets.

Qleet

Qleet provides managed Threeport control planes. Threeport is easy to try out and use in testing and development. As soon as you're ready to start using Threeport beyond that, Qleet can provide fully managed control planes for your team to use. Our managed Threeport service is built and managed by the team that built Threeport.