Today’s enterprises are under increasing pressure to deliver software faster than their competitors, differentiated solely by the quality of their applications and the developers who build them.
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.
What’s the difference between CI and CD?
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:
- Writes code
- 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:
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
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.
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 that need to be supported by your CD 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.
Stages
Workflows
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.
Environments
An environment is where you deploy your application; they represent the infrastructure which services run on.
This can be, for example:
- AWS
- Azure
- Google Cloud
- Your own data center
Your workflows deploy your applications to the necessary environment.
Pipeline
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:
Triggers
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
Summary
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)