Continuous Delivery and Continuous Deployment are often used interchangeably, but they each represent a distinct delivery process. One isn’t intrinsically better than the other, but each process makes sense for a different type of product.
What is Continuous Delivery?
Continuous Delivery is a (potential) final stage in your deployment pipeline. It happens after Continuous Integration (CI) and is the practice of automatically pushing code changes to staging, and eventually production. With Continuous Delivery, code changes will require manual approval before getting deployed to production.
At the point code changes hit staging, a CD pipeline may execute end-to-end, database, or UI tests. If those pass, staging will be ready for any final manual checks.
What are its use cases?
The Continuous Delivery pattern is used across all types of software. Since it has a wide range of implementations, it can be adapted to suit traditional web services, mobile apps, mission-critical applications, system software, mainframes, and firmware.
What is Continuous Deployment?
Continuous Deployment goes one step further than Continuous Delivery. In addition to automating staging deployment and any subsequent tests, it also automates deployment to production. This removes the manual gate that we see in Continuous Delivery.
Since Continuous Deployment is an entirely automated pipeline format, it requires CI/CD pipelines to be much more comprehensive. This means having a more complete automated test suite as well. If regressions are making their way through your CD pipeline with flying colors, you may want to return to a Continuous Delivery format instead.
What are its use cases?
Continuous Deployment is best for systems that can support fast rollbacks and canary/blue-green deployments. It makes sense most for web applications, particularly those with microservices architecture.
CI/CD pipeline != Continuous Delivery/Deployment
Continuous Delivery is a high standard, and takes time to properly build out. Having an automated pipeline is only one step towards true CI/CD. The CD philosophy, instead, relies on a set of principles that should be implemented by means of your pipeline.
- The pipeline should automate repetitive tasks, e.g. testing, building, linting, deploying
- If a feature doesn’t pass a stage of the pipeline, it should be reworked and sent through again
- Deployments should never bypass the pipeline
- Tests should happen before and after merging to main
- Code changes should be kept small in the spirit of trunk-based development
There are some excellent tips regarding CD best practices on minimumcd.org.
When should you move from Continuous Delivery to Continuous Deployment?
Just because Continuous Deployment requires more complex pipelines doesn’t mean it’s a better system than Continuous Delivery. However, some teams might benefit from it. What might affect that?
Many teams want to deploy upwards of three times per day. A true Continuous Deployment pipeline has no manual intervention: given that a feature passes all tests and requirements, it’ll get pushed automatically. For teams with reliable pipelines (e.g. those can catch bugs/regressions 99% of the time), this speeds up deployment velocity with little risk.
Because the bar for a reliable pipeline is so high, few teams have implemented Continuous Deployment. However, for lower-stakes services, it can be worth the effort. The ability to ship code changes quickly helps patch bugs or get features to a customer ASAP. Even if your team doesn’t use Continuous Deployment for all features (e.g. those that are high-risk), it’s valuable to know you can cut out days of cycle time when needed and still trust your code changes.
When should you favor Continuous Delivery?
Continuous Delivery is not to be mistaken with simply having a CI/CD pipeline. Done right, Continuous Delivery requires a thorough pipeline that automates multiple quality and security processes, as well as environment deployment. It sets up a review environment to best enable all manual checks/testing.
When you’ve implemented Continuous Delivery, how do you know whether this format is your pipeline’s ideal final state? It mostly depends on what you’re using your pipeline for.
If you’re developing mission-critical services, reducing risk is significantly more crucial than reducing lead time. Continuous Delivery ensures you have the resources for extensive manual testing. Even if your automated tests are top-tier, you can’t be careful enough before a deployment.
Other teams might thrive with Continuous Delivery because their processes are compatible with it. For example, teams that use trunk-based development and do code reviews on the spot have shorter deployment lead times. There may not be a huge time difference between Continuous Delivery and Deployment for these teams, and the extra layer of approval can be a good practice.
Continuous Delivery and Deployment Impacts on DORA
Teams that have implemented either Continuous Delivery or Deployment see a positive trend with their DORA metrics. The impact goes beyond the metrics themselves: good CD reduces stress, burnout, and lends itself to great DevEx.
DORA research recommends that teams absolutely adopt Continuous Delivery. Doing so will shorten deployment lead time and increase throughput, while also ensuring code changes are reliable and tested. Beyond that, CD eliminates delivery pain points and noise. Having a standardized process takes away guesswork and unknowns, so there will always be a straightforward procedure when things get derailed.
DORA recommends teams start with Continuous Delivery, and fine-tune it to the point of success, before venturing into Continuous Deployment. And remember, if bugs/regressions are frequently slipping past your CI/CD pipeline, your pipeline needs improvement.
Deploy with more confidence
Continuous Delivery and Deployment are essential for reliable, high-quality software. Both processes set high bars for new code changes. However, their effectiveness rests on their design: it’s up to your engineering or DevOps team to implement CD the right way.
A CD non-negotiable is end-to-end testing before merge. In order to hit that goal, you’ll need representative test environments to support your full stack, including database functionality. That’s where Shipyard comes in. With on-demand ephemeral environments, you can instantly build every PR in a production-like environment, and run your CI/CD against it. Eliminating infrastructure wait times enables you to test, review, and ship on demand. Try it free for 30 days. Your DORA metrics will thank you.
