Welcome to the first part of many in our DevOps 101 blog series. We’re going to break down the what, why, and the how of modern DevOps practices. Today, we’re starting with Continuous Delivery.
What is Continuous Delivery?
Continuous Delivery is a strategy for getting software ready for deployment. Rather than waiting for a predetermined release date, any time code is committed that passes our automated tests (Continuous Integration), an automated process kicks off to turn that code into a ready-to-be-deployed notice. All versions, past and present can be pulled down and deployed at any time.
That sounds nice, but why would you want that?
Stop me if you’ve heard this one before. The entire development team has been working on the next release for the last few months. A dozen different features and a brand new UI are all going to land at once. It’s going to be amazing, and management wants it delivered right now!
Now, if only someone could remember how to deploy to production.
It’s usually done by Sam. Problem is, right now, Sam is lying on a beach in Rarotonga on honeymoon….and certainly not answering their phone.
Back at HQ, the team knows there’s a docker image that needs to be deployed to AWS. Exactly how to build that image and get it on to the production is a little less clear. Sam runs some deployment scripts from their laptop to deploy. Since the team already has docker images used for local development and in the Continuous Integration pipeline, they figure they can use those. There’s some half-finished documentation from about six months ago that Sam wrote, although nobody is quite sure of its accuracy. Eventually, the team figures it out, and deploys the code into production.
The entire site breaks. Hard.
After a few hours, it turns out that the assumption that the docker image used for local development and CI are not the same as those used in production is horribly wrong. There’s a whole bunch of tools attached, including one that recreates the database from scratch on every deployment. All data is lost.
I hope they have backups!
So, what went wrong here?
We could blame Sam for not being available. We could blame the team for not knowing how to deploy. We could blame management for forcing through a feature that wasn’t ready yet.
The problem is that the knowledge for deploying isn’t centralised into a single accessible location. It’s in Sam’s head, and on his laptop. Neither of these locations is particularly accessible to other team members. Nor does it scale.
You may often hear about deployment to production needing to be documented, as a checklist set of steps to be repeated. While there’s nothing wrong with this, there’s an assumption built in that every deployment should be the same.
If that’s true, why not just get a computer to do it? Make it a repeatable, automatable task.
To do that, you’d need to be sure that what is deployed to production is the same as what was tested.
Enter continuous delivery and the artifact.
An artifact is a file, image, or other entity representing a complete deployment for a given version of the product. The exact nature of the artifact will depend on the operating environment and programming languages being used. Jar files, docker images, or an AMI are all examples of artifacts.
The role of Continuous Delivery is to create these artifacts, tag them with the information known as the release metadata about when and what they were built from, and push them into a place where they can be retrieved by our deployment software. This is the artifact repository. There are various artifact repositories available, depending on the type of artifact. Common tools are AWS CodeArtifact, AWS ECR (for docker images), JFrog Artifactory, as well as a plethora of other platform specific tools such as Docker Hub for docker images and PyPI for python modules.
Once the artifact is safely stored and tagged in the artifact repository, it’s the job of the Continuous Deployment framework to deploy that artifact to your production environment.
Stay tuned for the next article where I’ll look further at Continuous Deployment and how that works.
In the meantime, if you’re looking for guidance in Continuous Integration, Delivery, and Deployment, get in touch with us. Cevo is the trusted leader at the forefront of continuous delivery technologies, helping our customers stay competitive through innovative solutions and building capability on the AWS platform. Contact us today to learn more about how we can help your CI/CD practice.
