A 5-Step Guide to Good Continuous Delivery
A 5-Step Guide to Good Continuous Delivery
In this article, we review some best practices that DevOps development teams should keep in mind while working with continuous delivery.
Join the DZone community and get the full member experience.Join For Free
Discover how you can reduce your Kubernetes installation from 22 steps to 1.
At Caylent, we believe one of the major keys to successful DevOps implementation is the complete automation of Continuous Delivery (CD) and Continuous Deployment. Achieving full CD with your IT team unlocks many of the benefits that the DevOps ecosystem has to offer and ensures that you release code swiftly and with fewer errors.
Supported by the findings in the 2017 State of DevOps report, with the combined power of CD and DevOps high-performing IT teams can deploy code 46X more frequently than low-performing ones. Furthermore, you gain:
- Meantime to recover: 24X faster.
- 2555X faster lead time, from starting code to delivery.
- Considerably lower failure rate: Just 0-15% rather than 31-45%.
Why Continuous Delivery?
CD aims to significantly reduce your risk level by enabling deployment of small, high-quality batches of code quickly and sustainably. The concept works in line with Continuous Integration, which focuses on helping your team prepare for deployment with ease.
A very interesting theory to note is that CD has also been demonstrated to positively impact the level of happiness and engagement of your team.
Put simply, a better work process = high-quality code = high-quality products = happy customers = happy IT team.
Continuous Delivery vs. Continuous Deployment
The difference between the two is minimal, and often, the terms are used interchangeably; the variation only comes in at staging or pre-production with a manual acceptance test for Continuous Delivery. At this point, the product owner will manually merge and push the code to production.
How Docker Improves CD
Docker gives us the ability to build and distribute immutable artifacts so that we can retain the exact same build artifact through testing, pre-production, and production. In comparison to Chef, Puppet, or other general server builders, Docker allows users to build first then push to servers, whereas Chef and Puppet users must build and modify the servers in real time. Once built, Docker allows you to move an artifact through the pipeline intact.
This advantage improves the artifact’s robustness and reduces the risk of failures and blockages in the production pipeline. Building an immutable artifact once also allows us to test the image repeatedly via local, QA, staging, and production environments. Rollbacks occur in seconds rather than minutes, and deployments are fast and straightforward. Finally, Docker further decouples server config from application deployment.
The 5 Steps
Caylent’s best practices when it comes to using Docker to empower CD can be broken down into these 5 steps:
Where possible, build your packages once and once only. Then move your immutable artifact through your CD pipeline to test it from one repository to the next. As it migrates through the pipeline, leverage Docker’s tagging system to promote your image and gain the most stability for deployment.
Decouple your code, database migrations, and infrastructure changes to independent pushes. Keep them separate and your code chunks as small as possible.
Run your deployment types in the exact same manner in each environment, and in at least one environment that’s an identical mirror of production. Use the environment parameters and secrets within Docker to pass environment variables at runtime without drastically changing your artifact. Consider changes to these as Infrastructure-level change.
Run tests as part of the container build process and automate the testing of all your deployments. Aim to combine builds and tests together to keep the log files intact and easy to decipher. If a build fails it will remain in the loop, rather than being promoted to the next environment.
Keep your stacks and environments similar. If you’re running massive web stacks on your production site, this may be difficult in development and staging, but things like your content delivery network (CDN), proxies, and caches should all be replicated in staging.
While Docker makes it easy to deploy code using CD, it’s important to follow these best practices to build, test, and deploy correctly, rather than falling into bad habits.
In the companion article to this one, I cover the four main deployment types for Continuous Delivery with Docker. Click here for Docker and Continuous Delivery Deployment Types
Published at DZone with permission of Stefan Thorpe , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.