Continuous Delivery
CD is the process of taking an artifact throughout the various steps necessary for it to be deployed to customers into production.
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 are a Pipeline, Stage, and 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
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
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 consists of a workflow with the following steps:
- 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 that services run on. This can be, for example:
- AWS
- Azure
- Google Cloud
- Your own data center
Your workflows (see Workflows, above) 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
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.
Overview of Steps
- Access Cloud Environments
- Provision Infrastructure
- Change Management and approvals
- A release strategy
- Verification of deployments (performance/quality)
- Rolling the software back in the event of a failure or anomaly/regression
Why do it?
Continuous Deployment offers a range of benefits including reduced deployment risk, faster time to market, and happier development teams. Continuous Delivery ensures you are able to get changes of any type into production “safely and quickly in a sustainable way.” This a quote from Jez Humble on Continuous Delivery. Since you are deploying smaller changes and more often there is less risk in delivering software value.
