What is Continuous Deployment (CD)?

If your integration and deployment processes are completely manual, with code freezes, an all-hands-on-deck testing strategy, and an anxious company-wide holding of breath on release day then hourly, uneventful deployments might sound like a fantasy.

But the reality is that a whole host of organizations are turning to this approach, from big names like Netflix, Etsy and Amazon to smaller companies trying to keep pace with the market. Adopting continuous deployment system has enabled them to cut their release time from weeks or even months to hours. For an increasing number of industry sectors, being able to deliver features fast and respond quickly to feedback is becoming essential.

As an extension of continuous integration and delivery, continuous deployment depends on a fully automated test and build deployment process to ensure that speed doesn’t come at the cost of quality. But implementing continuous deployment effectively needs more than that solid foundation.

When planning how to implement a continuous deployment system, a key question to consider is how your changes will be released. Aside from choosing a rolling update over taking servers offline to avoid frequent interruptions to online services, you can also make the rollout an extension of your automated testing process.

A canary deployment limits deployment of the updated code to a small percentage of users, who become unwitting testers in production. By monitoring behavior and usage metrics, you can check that the new release has not introduced new failures before rolling it out more widely.

Some companies have taken automation further with a canary confidence score, which automatically compares a whole host of metrics against a baseline. Rollout continues automatically only if the score exceeds the specified threshold, while the metric analysis provides a starting point for further investigation into potential issues.

A blue/green build deployment process is a common technique for organizations implementing a continuous deployment system, as it makes it easier to roll back a release in the event of a problem by keeping the old code online until you’re confident that the changes are working as expected. If required, you can follow an initial canary deployment with a blue/green rollout.

Whether you’re running a blue/green deployment or rolling out direct replacements, monitoring the health of the production system is essential if you want to be able to respond quickly to any bugs that have slipped through the release process.

Keeping an eye on particular metrics that indicate the health of your system, from disk space and CPU usage to numbers of requests or transactions, and comparing them against a baseline can provide an early warning if things aren’t behaving as they should. You can then decide whether to roll back the change or roll forward by putting a fix through the pipeline.

Before jumping on the continuous deployment bandwagon, it’s worth taking a moment to consider some of the issues that typically crop up when adopting CD.

The software development lifecycle involves more than just code changes. User research, product marketing, interaction design, documentation, commercial, legal and support teams all have a role to play.

If you haven’t laid the groundwork with your stakeholders and engaged with them to understand what they need from the release process, moving to continuous deployment can make them feel like development is out of control. That can result in manual checkpoints and review stages being introduced to slow the process down, or even in the whole continuous deployment system being rejected as a failed experiment.

Creating a culture of collaboration is essential. Involving other teams throughout the development process so that their input – on design, security issues, terminology or compliance – can be incorporated early on is one example of how short feedback loops make the software development lifecycle more efficient. Just as important as inviting input is providing visibility of what’s being released when. Keeping stakeholders informed can be automated with the help of a CI server, a continuous build deployment tool, to disseminate information via dashboards and notifications.

Sometimes visibility of what is coming alone is not enough. When you’re working on a larger feature or need to control timing of a release, simply deploying each commit to live once it has passed all tests is not ideal.

Feature flags are one option for controlling visibility of code in production, with the advantage that the code is live so that you can monitor for unexpected failures. Another approach is to use a dedicated branch deployed to a separate pipeline that doesn’t automatically push to production, thereby combining both continuous delivery and continuous deployment to suit your needs.

When done right, continuous deployment can help teams automate the deployment of software to users. Following continuous deployment best practices can help you streamline the process and obtain better results. For instance, it is important to monitor and measure your pipeline regularly for any signs of trouble. It also makes sense to get the whole team on board to build an effective CI/CD pipeline.

It is easy to confuse the two, but continuous deployment and continuous delivery are both distinct parts of the CD side of the CI/CD pipeline. While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.

Continuous deployment uses automation to maximum effect in order to deliver functionality to users fast without compromising on quality. Fundamental to this DevOps practice is regular and rapid feedback. Automated tests, production monitoring, collaboration with other functions and users’ behavior all provide inputs to the software development process. By working in smaller chunks and releasing frequently, you can keep adjusting based on feedback and continuously improve what you deliver.