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.

How does Humanitec Platform Orchestrator improve continuous delivery?

Humanitec Platform Orchestrator improves continuous delivery by enabling Dynamic Configuration Management, which allows for the generation of application and infrastructure configurations with every git-push. This approach reduces configuration overhead, decreases the likelihood of deploying workloads with faulty dependencies or insecure configurations, and provides end-to-end self-service capabilities for developers, reducing dependencies on other teams and waiting times.

Some benefits of using Humanitec Platform Orchestrator for continuous delivery include:

• Reducing configuration overhead and maintenance of varying formats.
• Reducing the likelihood of deploying workloads with faulty dependencies or unsecure, non-compliant configs.
• Providing end-to-end self-service capabilities, such as the ability to add resources like databases, file storage, or DNS.
• Full visibility into what’s running where and in what environment.
• Enabling Dynamic Configuration Management, which allows for functionalities like spinning up ephemeral or PR environments, diff functionality to understand and debug deployment changes, and precise, on-point rollbacks.

Humanitec Platform Orchestrator sits post-CI and is integrated with adjacent tools such as image registries or secrets managers directly and to resources and compute through Drivers. It reads the workload specification (the environment-agnostic request) and generates app- and infrastructure configurations with every deployment. It can also execute the deployments and manage the lifecycle of resources. Lear more how to integrate Humanitec into your existing CI/CD setup.