Continuous deployment takes the DevOps practice of automating build, test and deployment steps to its logical extreme. If a change to the code successfully passes all previous stages of the pipeline, that change is automatically deployed to production without any manual intervention. Adopting continuous deployment means you can get new features to your users as fast as possible, without compromising on quality.
Continuous deployment is underpinned by a mature, well-tested continuous integration and continuous delivery stages. Small code changes are regularly committed to master, put through an automated build and test process with promotion through various pre-production environments, and – if no issues are discovered – finally deployed to live. Building a robust and reliable automated deployment pipeline means releasing can become a non-event that takes place multiple times a day.
Although automating the final rollout to live is not appropriate for every software project, you can still benefit from some of the individual elements involved in implementing continuous deployment effectively. This article will explore what’s involved and what to bear in mind before taking this last step towards continuous everything.
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 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 build, test and 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 continuous deployment, 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 deployment process is a common technique for organizations practicing continuous deployment, 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 continuous deployment 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 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.
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.