DevOps Strategies: Release Management Part 1

DevOps Practices - Release Management

In this blog posting we describe four general release management strategies that support DevOps. These strategies, from least effective to most effective, are:

  1. Release windows (slow cadence). A release window is a period of time during which one or more teams may release into production. A release slot is subset within that release window (and may be the entire window) during which a team may deploy their solution into production. For example, your organization may have a policy that production releases occur between 1am and 5am on Saturday evenings (the release window) and that up to four releases may occur during that window (the release slots). In lean terms, a release slot is effectively a Kanban card that allows a team to deploy. Release windows tend to align with periods where system usage is lower, although in the modern world of global 24/7 operations these periods have all but disappeared. With a slow cadence approach to this strategy the release windows occur far apart, as seldom as once a week or even longer. The advantages of this approach are that it provides a consistent release cadence to business stakeholders and it provides consistent release date targets for delivery teams. The primary disadvantage with slow cadence release windows is that they become bottlenecks for release management processes that need to support multiple teams. There are only so many release slots available during each window and this number can be easily exceeded, forcing teams to aim for a future release window. This problem becomes exacerbated when teams start to move to a continuous delivery strategy.
  2. Release train. The idea with a release train is that every team involved with that “train” has the same release cadence – for example this train releases once a quarter, or once a month, or even once a week. This strategy is commonly used in large programs, or teams of teams, where the individual teams are each working on part of a larger whole. Having the common drumbeat of a release train provides a consistent release schedule for stakeholders and serves as a rallying point for development teams. The train metaphor works quite well in practice. If your team misses the release date, if you miss the train, then the train goes on without you and you need to wait for space on the next on. Dependencies are also respected. For example, if several components need to ship together they must all go on the same train (similar to a family taking a trip together). The primary disadvantage is that development teams are constrained to a common release schedule, making it difficult to support lean or continuous delivery strategies. A potential disadvantage is that release trains may also suffer from the bottleneck problems of slow cadence release windows.
  3. Release windows (quick cadence).  To support continuous deployment, particularly across many delivery teams, you will need a large number of release slots. The implication is that you will also likely need more release windows more often. The advantage of quick cadence release windows is that they are less likely to suffer from the bottleneck challenges associated with slow cadence release windows and release trains.
  4. Continuous release availability. With this approach delivery teams are allowed to release their solutions into production whenever they need to. In many ways this is simply an extension of the release window strategy to be 24/7. This is the only strategy that truly supports continuous delivery. To make it work a host of DevOps practices are required, such as fully automated deployment, fully automated regression testing, feature toggles, self-recovering components, and many others are required.

Our experience is that most enterprises today employ a slow cadence release window approach although are starting to evolve into the quick cadence version of this strategy. This is usually motivated by the adoption of agile techniques by solution delivery teams and more often than not by continuous delivery practices. We also see large programs take a release train approach, a strategy pioneered in the 1990s by large software companies such as Microsoft and Rational that sold software suites comprised of many products that needed to be shipped together. In recent years the OpenUP and SAFe frameworks have popularized the release train strategy. The strategy of continuous release availability is commonly used in advanced DevOps organizations such as Etsy and Amazon.

An important point to be made is that there are several options available to you, each of which has its advantages and disadvantages.  No single approach is perfect, and no single approach works in all situations.  You not only need to have choices, it’s good to have choices.

The next blog posting in this series continues with more release management DevOps strategies.


Have any Question or Comment?

5 comments on “DevOps Strategies: Release Management Part 1

Valentin Tudor Mocanu

In some cases, IME the strategy it is a constraint. Some examples:

– occasional train , where the occasion is a major reason of changing the product (as a major version upgrade); the smaller reasons of change (features or improvements) could take this train or not. In some cases, this strategy could be a constraint, even we usually have quick cadence or continuous delivery – the product could need a major upgrade for various reasons as platform changes
– occasional quick cadence – the business could need some quick changes (or significant fixes) independent of usual slow cadence of the development; if this occasional quickness is not realized, the business will suffer

Than mean imo we should be prepared for all variants, because the strategy could be imposed by some constraints from external context.


I was just keen to understand if we should have a set up whereby developers as generalising specialists are incharge of deploying their own code into live vs a set up where we introduce a team for release management specifically (which would have handhsake meeting with the developers)? Should the focus be on creating generalising specialists vs release specialists?


It depends. 😉

In smaller organizations it’s typically better to have the delivery teams responsible for deploying their own stuff. BUT, when you have more teams working in parallel the chance of a serious collision goes up so the greater the need for someone focused on release management.

As a matter of fact we’re just about to release an updated version of the Disciplined DevOps article that goes into this a bit, just a bit, more.


Thanks for the clarification Scott.. really keen to read the article you mention.


Leave a Reply

Your email address will not be published. Required fields are marked *