Grounds for Divorce: Why Deployment Should Be Decoupled from Release

In the rush to make applications and services more productive for the business, DevOps engineers are often seen pushing the boundaries between deployment and release. A step back, ensuring greater distinction between the two, should be encouraged by senior software engineers and other key leaders, to restore those boundaries and ensure product quality and happier users.

Deployment ≠ release

Software development continues to evolve and the pressure on IT and developers to deliver product continues to grow. Ever shorter development times, more pressure to go live and to speed up processes continues to mount up.

In the increasingly agile and DevOps-focused environment of modern business, any shortcut to get updates and new products running live can be a tempting one. There are also release on-demand services that treat deployment and release as the same. Yet, while it’s possible to intermingle the terms and stages through deployment and release, they aren’t typically interchangeable, for good reason.

Whatever the good practices we’ve seen in DevOps guides, IT service management recommendations and thought leadership pieces, the pressure on developers to deliver and for IT to have a greater business impact continues. While they’re helped by automation and improved development tools, we continue to see more cases of teams rushing the deployment phase as part of the live release.

Traditionally, deployment marks the final steps before release. This includes the box-ticking processes of preparing for deployment, ensuring that service components and the target environment are all that is expected, then testing the final code in a production environment before final acceptance and pushing the end product to eager users.

All of those steps should happen before release to avoid production disasters, errors and ultimately unhappy users. With the subsequent impacts on productivity and time spent error tracking and recovering the situation, the cost can be substantial, especially for mission-critical or high-profile applications. 

Why is it important to decouple deployment from release?

Decoupling – keeping the two distinct – is useful, if not vital, as part of the effort to avoid having to resort to quick hotfixes or rollbacks, all of which can have an impact on productivity. The larger or more complex the product, the more likely there is to be an issue.

While the temptation to mix and match deployment processes with release might appeal to some, they won’t be happy when there’s a string of complaints from various business departments once things start to go wrong. And, if the outage or bills mount up, more senior roles will be getting involved quickly.

Decoupling deployment from release helps to reduce risk, and makes any issues more likely to be found before they hit actual users. Decoupling processes doesn’t mean that doing those deployment steps first need be particularly slow or time-consuming either. Instead, development teams can use rapid feedback testing loops and other methods to get all the approvals and tests done, before the application goes anywhere near live users.

Learn more: 6 Key Challenges Holding DevOps Engineers Back

Decoupling reduces risk and improves operations

Reducing or eliminating the risk is more valuable to the business, whatever the extra time taken, compared to a coupled release going wrong. As DevOps teams become more assured with their point or minor releases, they might start to couple the deployment and release processes, but uncoupling when a major release or upgrade is due can add to the complexity, adding to the chaos of a big update going wrong.

As a business decision process, decoupling them also means that team or department leaders can decide when users gain access to new features from the latest releases. This may be vital if they’re tied into new products or services within the business or for customer-facing roles. Giving them early access may see them untrained or unprepared to use them, increasing the risk of mistakes. 

Decoupling and going through formal deployment methods ensures a high quality and timely release. This will help the business with its compliance requirements and mitigate the risk of impacting live services.

And, with a decoupled approach, performance and success metrics will be more positive than those of businesses trying to speed releases through unnecessarily. With happier users, teams can focus on positive features feedback rather than the negative sentiment that comes with most bug or issue reports.

Release too, is no longer a black and white issue. DevOps can provide varying levels of release, including dark launches that see a release go live without being accessible by users. There are also feature toggles, enabling management or users to enable new features, while so-called canary releases can be targeted at a specific set of users.

This highlights the need for a decoupled deployment to ensure the product is ready for those audiences, whereas a coupled release might see unintended consequences or issues further down the line after any initial release seemed to have been successful.

Final thoughts

IT efforts will continue to feel the pressure as teams face sizing pressure and cost controls demand they do more with less. DevOps and increased automation won’t solve every problem or speed up every process, so teams need to take the time to ensure they can decouple when appropriate, and only risk running deployment alongside release when they’re truly confident and on top of their products and processes.

The subject of decoupling deployment and release has been a hot topic for a few years now, and likely will remain so until the majority of businesses have seen the light and split those processes into distinct parts of their overall development strategy.