Today’s enterprises are under increasing pressure to deliver software faster than their competitors, differentiated solely by the application quality 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 must have heard & probably just assumed that CI/CD means writing scripts to build pipelines to deploy applications. Well, you’re sort of right. First, let’s contrast & compare 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
- The artifact is stored within a repository
That’s it. Following is a visual representation of the explanation above:
Continuous Integration 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 a 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 has its own deployment requirements. For example, the Node.js application will require you to package your service in a different way to prepare it for deployment. This packaged and ready state is an artifact. So, an artifact is a service that is built, packaged, and ready for deployment.
The Six Stages of Continuous Delivery
CD essentially includes 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
To understand the basics of CD, There are a few important terms you have to become familiar with: pipeline, stage, and workflow. When you kick off a deployment, your artifact goes through various stages in order to be deployed.
Stages
Workflows
Each stage requires some actions with that artifact. These things that you’re doing are referred to as a workflow.
Workflows typically automate three things: Service deployment, 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 Blue/Green & Canary deployments. As you progress within your later stages and approach production, you need a release strategy that ensures the safety and reliability of the deployment.
So, your product 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 on which services run.
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 used to describe all the stages (and their corresponding workflows) stitched together. Remember, each stage has a workflow. Thus, a pipeline assembles the stages and their corresponding workflows. A pipeline is an umbrella term for all of the pieces working together.
Here is what a CD pipeline looks like:
Triggers
A trigger is an event that occurs 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 the 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 test/deploy your application.
Oldest comments (0)