As a result, more and more organizations are turning to continuous delivery (CD) to improve their ability to plan, build, test and release applications to market quickly and at scale.
Your company is interested in learning how to leverage continuous delivery for faster software deployment, but doesn’t know what all the terms and concepts mean.
Luckily, this article can help you: read on for a guide on the basic terms and concepts around continuous delivery and why CD is essential.
You’ve heard of the term CI/CD and have probably just assumed it means writing scripts to build pipelines to deploy applications, Well, you’re sort of right. First, let’s compare and contrast CI and CD.
CI is about taking code-to-artifact.
So, basically, a developer:
That’s it. Here is a diagram of what I just described, for you visual learners:
Continuous Integration is a problem that has a mature set of tools, technologies, and established best-practices. There are a plethora of vendors and you’re most likely using one of them.
So what happens after the artifact is ready? This is where CD comes in.
Service – A service is self-contained software that serves as part of a collection of services that make up an application. Common examples are Docker containers, Kubernetes pods, or a single Node.js app.
Artifact – Each service contains its own deployment requirements. For example, your Node.js application will require you to package your service in a particular way to prepare it for deployment. This packaged and ready state is an artifact. So, an artifact is simply a service that is built, packaged, and ready for deployment.
CD is essentially made up of the following stages:
Once an artifact is ready for deployment, you need to take it through these six phases that need to be supported by your CD pipeline.
There are a few important terms you have to become familiar with to understand the basics of CD: pipeline, stage, and workflow. When you kick off a deployment, your artifact has to go through various stages in order to be deployed.
Each stage requires you to do something with that artifact. These things that you’re doing are referred to as a workflow.
Workflows typically automate three things: deploy the service, test and verify the service and then rollback (if necessary).
Say, for example, stage 1 is:
This is your stage 1 workflow. Once stage 1 is complete, you then go to stage 2, stage 3, and so on.
Here is a visual:
Canary and Blue/Green Strategies
A common attribute of workflows is a release strategy. Specifically, the most popular release methodologies are Canary and Blue/Green deployments. As you progress within your later stages and approach production, you’ll want a release strategy that ensures the safety and reliability of your deployment.
So, your product (e.g. Stage 4) deployment in your pipeline will want to incorporate a release strategy within its workflow.
An environment is where you deploy your application; they represent the infrastructure which services run on.
This can be, for example:
Your workflows deploy your applications to the necessary environment.
A pipeline is a term to describe all of the stages (and their corresponding workflows) stitched together. 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.
So, here is what a CD pipeline looks like:
A trigger is an event that happens to kick off your pipeline. An event can be any of the following:
That’s it! Now you understand that a pipeline consists of stages. Each stage corresponds to an environment.
Each stage has a workflow that does what is required to deploy/test your application.
(Featured Image Source: plutora.com)