You have a real interest in Continuous Delivery, but you don’t have a clue as to what all the terms and concepts mean. Neither did I before joining Harness. Lucky for both of us, this article is designed to get you from 0-60 with the basic terms and concepts.
Many of you are newly exploring CD as it has become a major bottleneck within your SDLC (software delivery lifecycle). You’ve attempted to solve for it by extending your existing CI tools (e.g., Jenkins) and/or have written many custom scripts to make this happen.
I’m hoping with this article that you’ll walk away with a basic understanding of CD and understand where your process is lacking, and how you can benefit from upgrading to a real CD solution rather than building your own. However, mostly, I want you to get a basic understanding — conceptually — on what the heck CD actually is. Also, if we’re lucky, 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.
CD versus CI
CI is about taking code-to-artifact. So, basically, a developer:
- Write codes
- Checks in code
- Code goes through a build process
- An artifact is created
- Artifact is stored within a repository
That’s it. Here is a diagram of what I just described, for you visual learners:
Now, you’ve probably already solved for this. As a matter of fact, almost everyone already has. 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.
What is an Artifact/Service
A service is a self-contained software that serves as part of a collection of services that make up an application. Common examples are:
- Docker container
- Kubernetes pod
- A single Node.js app
Each service contains it’s 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.
The Six Stages of Continuous Delivery
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.
Don’t get too confused by this; we’ll come back to this later. For now, just understand that there are these six phases that need to be supported by your CD pipeline.
Speaking of which, what is a pipeline?
What is a Pipeline, Stage, Workflow
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:
- provisioning a QA environment in AWS
- deploying my artifact to a QA environment
- running a bunch of tests
- tearing down the environment
- verify the health of the application
- rollback, if necessary
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:
- Google Cloud
- Your own data center
Your workflows (see Workflows, above) 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:
- Merging your Git branch into master
- A new artifact is available in your artifact repository
- A new .tar artifact file has been uploaded to a folder for deployment
- A recurring time
- A webhook
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.
Be sure to check back as I’ll cover more advanced topics such as Continuous Verification (CV), change management, and more. If you can’t wait, I don’t blame you. Sign up for a free trial today! And, if you didn’t already know, we also have a free (forever) community edition.