Welcome to the CD Cheat Sheet! This cheat sheet should help you learn the basics of CI, CD, several release strategies, artifacts, and more. 

We’ll also run you through what a Continuous Delivery pipeline should look like, including Environments, Stages, Workflows, and more.

Continuous Delivery Fundamentals

Continuous Integration

CI is the process of taking a developer’s code throughout the various steps necessary for it to be ready to be deployed as an application. Or, to be more accurate, an artifact (see artifact below).

Continuous Delivery Fundamentals - Harness - what is Continuous Integration

Continuous Integration

Continuous Delivery

CD is the process of taking an artifact throughout the various steps necessary for it to be deployed to customers into production. Specifically, the six major steps are: accessing clouds, provisioning infrastructure, change management and approvals, a release strategy, verification of the deployments (e.g. performance/quality) and rolling the software back in the event of a failure or anomaly/regression. 

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - stages of CD

Continuous Delivery


A service is self-contained software that represents a distinct business function, use case or task. Technically, it’s an individual run-time. For example. This can be a Dockerized container or simply a Node.js application.


An artifact is a packaged service/application code that has gone through a CI build process and is now ready for the CD process. Simply put, it is a service that is built, packaged, and ready for deployment. A simple example would be a docker container. 

Artifact Repository

This is where you store your artifacts once they’ve gone through a CI build. Common examples include Artifactory, Nexus, and ProGet.

Continuous Delivery Pipelines


An environment is where you deploy your service or application to; they represent the target compute infrastructure (aka Clusters). Most dev teams have one or more environments (e.g, dev, QA, staging, production).


A pipeline is made up of one or more stages, a stage represents tasks and tests that an artifact must to go through and satisfy in order to proceed to the next stage. You can create and map stages by environments (e.g. dev, QA, staging, prod) or you can map them through functional tasks or tests (e.g. regression testing, performance testing, security testing).

A stage can also be a governance approval step that gates/govern how artifacts are promoted between environments.

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - pipeline stages

Pipeline Stages


Workflows typically automate three things: deploy the service, test/verify the service, and then rollback the service (if necessary). Basically, it’s all the stuff you have to do in order to complete that stage. If you’re in a Dev stage (e.g. Stage 1) you might have some security scans you want to complete. If you’re in a QA stage (e.g. Stage 2) you might have smoke, regression, or automated tests you want to run against the service.

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - stage workflows

Stage Workflows

Parallel Steps

Executing workflow steps in parallel that have no dependencies on each other. This is in contrast to steps that are sequential.

A popular example of this is deploying multiple services to multiple clusters or clouds within the same stage of a pipeline. This is common in microservice architectures.

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - parallel steps

Parallel Steps


A pipeline is a term to describe all of the stages (and their corresponding workflows) stitched together that relate to one or more services. Remember, each stage has a workflow. So, a pipeline stitches together stages and their corresponding workflows.

A pipeline is an umbrella term for all of the pieces working together. 


A trigger is an event or condition that executes your pipeline.

Smart Rollbacks

The ability to automatically rollback your deployment if it fails a verification test or stage (see below, Continuous Verification). 


Variables that are set and passed to your application throughout its lifecycle in a pipeline.

Harness variables come in two flavors:

  • Harness built-in variables: There are variables scoped to different entities—such as Applications, Services, Environments, and Workflows—and variables that provide information about deployment environments.
  • User-created variables: You can create variables at the account level and application level, which can be used across your Harness applications. You can also create variables in Application entities, to be replaced by users when configuring or deploying a CD pipeline.

Passing Variables from Triggers

You can also pass variables from a Harness Trigger into a Harness Workflow to be used during Workflow steps or configuration or as part of a Pipeline. This process can be valuable when you want to use information from the condition that initiated the Trigger as settings in your Workflow at runtime. 

Secrets Management

Private and secure variables that are exposed to clouds, services or tools within a pipeline. Common examples include database access credentials and API tokens. Harness allows for the integration of existing secrets managers (e.g. Vault, KMS, Azure KeyStore etc.) or the ability to use the existing built-in secrets manager within Harness.

Release Strategies

Canary Release

A release methodology that reduces risk and exposure to both customers and the business. Canary is a method of slowly releasing in small stages across nodes within your network before a full deployment. 

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - canary deployment strategy

Blue/Green Release

A blue/green release is replicating a production environment and switching traffic between lives environments as each non-live environment receives the later update.

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - blue/green release strategy

After-Hour Releases

The painful, all-hands-on-deck, release process that companies utilize when they don’t have a proper CD solution in place and everything is done manually. Expect lots of sleep-loss, anxiety, and stress. Your kids won’t like you, either, when you’re in this stage. 

Continuous Verification

When artifacts are promoted to an environment (e.g. dev, QA, staging or production), the performance/quality of that artifact must be tested and verified for a finite period of time to ensure the pipeline stage can proceed and complete. A modern CD platform will test artifacts immediately using data (metrics/events) from your existing performance and log tools and — if necessary — rollback the artifact.

For example, does the response time of end-user requests increase or decrease post-deployment? Does the service throw any new errors or exceptions post-deployment?

24/7 Service Guard

Using the same models as continuous verification, 24/7 Service Guard monitors your services/applications on a 24/7 continuous basis vs. a finite amount of time post-deployment.

Continuous Delivery Fundamentals - Harness - what is Continuous Delivery - 24/7 service guard feature

Orchestrating continuous monitoring of services among major performance monitors

Get With the Program

We really hope this short cheat sheet was helpful and you learned a thing or two about the basics of CI, CD, and more. If you’re interested in Harness, request a demo today!