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
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
A blue/green release is replicating a production environment and switching traffic between lives environments as each non-live environment receives the later update.
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.
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.
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!