The Benefits and Best Practices of Continuous Delivery

First extensively covered as a practice by Jez Humble and David Farley but also covered by Martin Fowler of Thoughtworks, Continuous Delivery, engineering teams produce software in short, discrete cycles. The practice helps teams ensure that they can release software at any time in the knowledge that their changes are tested and successfully built.

On the path to a fully automated and continuous development workflow, Continuous Delivery (CD) is often the second step after Continuous Integration (CI). During the CI step, you typically automate the build and testing of code, every time a team member commits changes, either to all branches, or specific branches.

The CD step extends CI. If your tests pass in CI, then during the CD step, you take the built artefacts from the CI step and deploy them automatically to other developer environments (staging for example), and manually to production when you’re ready. You can make this manual deployment whenever you decide, but to benefit from continuous development practices, you should look to deploy as regularly as possible.

If you wish to go further, then the final step is Continuous deployment (a different CD), which fully automates your development workflow to also deploy the built artefacts to production, and into the hands of users. Then your developers can complete a bug fix or feature, have it pass testing and review, and deployed straight into the hands of customers, potentially in a matter of minutes.

This article focuses on Continuous Delivery (CD), its benefits, and how you and your team can start using it with your projects.

The Benefits

Small, Identifiable Changes

CI and CD focus on small, discrete code changes that reflect a particular feature or bug fix. These smaller changes are easier to test, to collaborate on, and to fix and revert if they introduce issues that automated testing doesn't identify.

Smaller, more manageable tasks can help your team feel like it’s making more progress through a backlog, instead of large, broad tasks that take a long time to implement and deliver to users. This gives better visibility of what a team is working on to team leads, meaning they can focus more on their tasks, and spend less time asking developers for progress reports.

Measurable Success

Practising CD as part a general DevOps strategy helps you better measure and improve certain DevOps key metrics important to your project.

For example, if deployment frequency and speed are important to you, implementing CD effectively and meaningfully can increase the rate. However, until you implement continuous deployment, a production deployment still relies on a manual process, so make sure you define a policy to not create a bottleneck in your continuous workflow.

Mean Time to Recovery (MTTR) is an important metric to measure as it directly relates to customer satisfaction. If rolling out a change breaks features or your entire application, CD can help you roll back to a last working build. Keeping a close eye on this metric helps you see if CD is helping you keep this rate low, or if your process needs tweaking to get it lower.

Increased User Satisfaction

Users like new features, but they especially like new features that reflect how they use software. If you iterate quickly, and (crucially) analyze how people use your software, you can build features that reflect this. Likewise, as usage changes over time, or during particular periods in time (holidays, for example), you can change features to match this new usage or remove them completely.

Best Practices for Implementation

How long testing, building, and delivering your artefacts takes can depend on the complexity of your application, and what programming language(s) it uses. But as you are delivering artefacts to non-production environments with CD, the waiting time shouldn’t hold up developers from working on other tasks. With many CI and CD services, you can run several parallel tests and build processes based on different branches, meaning you can switch between changes in progress while waiting.

Build on a Solid Base

Before you start down the CD path, you should already have a stable setup and experience with CI, and trust that your tests are meaningful and helpful.

You should avoid what developers call “flaky tests”, tests that don’t help you identify problems with the code changed or added. Tracking them down is sometimes hard, but generally, a flaky test is a test that gives different outcomes, even when there are no changes in the source code or execution environment.

Choose your Tools

You need a service that can handle CD and CI, or you can use a separate service for each task. There are many options to choose from, and deciding which suits you depends on the languages you use, useful features, integration with other tools, and pricing.

If you have a service or tool that only handles CI, then Humanitec can help you by adding a CD process.

Generate Reproducible Builds

Reproducible builds result in identical output artefacts from building code, whether that happens on a developer machine, a testing environment, or in production. Identical builds give increased confidence that code that works on a developer machine, also works on production.

Using containers such as Docker or Rkt can help you create identical environments across your workflow. You can replicate the production environment on any machine and reduce the chances of differences in environments that used to be common sources of problems.

Get Feedback

While CD doesn’t automate deployments to production versions of your application, you can still use the non-production builds for wider user testing feedback. You can deploy these builds to ephemeral environments, dark, beta, or canary launches, and how public you make them is up to you, often these releases are reserved for the most dedicated customers.

Some development teams hide features behind flags they can enable for users that match certain criteria instead of releasing different builds to different users. This is an especially common technique for larger software projects, where product teams want to experiment with multiple features at once. You can use feature flags on production and non-production environments.

Humanitec - The Continuous Delivery API

As an API dedicated to continuous delivery, Humanitec can connect to any CI tool you use, and generate environments as you need them. In addition to creating environments, Humanitec helps you provision any services your applications need that are typically external to your core application code, such as databases, message queues, or caches. As an added bonus, Humanitec can provision databases and other resources outside the cluster for you during the deployment process, helping you maintain application state across environments. Explore the full functionality of Humanitec in our learning hub.