DevOps: Strategies for Organizing Release Management

In this blog posting we describe two issues for organizing your release management strategy: How to scope release management and how to organize the team.

There are two fundamental issues to consider when scoping your release management efforts:

  1. Paradigm support. Will your release management process focus on supporting one paradigm, such as agile/lean teams or will it provide a more holistic strategy to also support agile/lean teams, traditional teams, iterative teams, and even ad-hoc teams? Many people who are currently writing about release management tend to focus on a single paradigm, although they may not explicitly state this, but the reality is that most enterprise-class organizations need multi-paradigm support in practice.
  2. Domain support. Will your release management process focus on IT-related issues or will it address the full range of business-related release issues? IT-related release issues include deploying new software and hardware into production. Business release issues may include marketing campaigns, training your sales force, and organizing external support mechanisms for end users to name a few. This is particularly important for commercial solutions being produced for the end customer of your organization.

These two issues lead us to the following quadrant chart depicting the potential scope for release management:

Scoping IT Release Management


From a Disciplined DevOps point of view we of course promote a Holistic Enterprise scoping strategy. Whatever scoping strategy you choose your release management strategy will need to be able to support the scaling situations faced by your delivery teams. This includes teams of various sizes, different levels of geographic distribution, dealing with different levels of domain and technical complexity, teams that are organizationally distributed, and teams in compliance situations.

There are three strategies to consider for organizing your release management team:

  1. Operations led. In many small to medium-sized organizations release management is one of many activities that are performed by the operations team. With this approach a “release team”, in some cases an individual, is put together to release a solution on a project-by-project basis. Although there is often a hand-off point from the development team to the operations team, the operations team may require several members of the development team to be actively involved with the deployment. The advantages of having operations manage releases are that they are very familiar with the current state of your production environment and they know what other releases are happening in parallel (if any) and thereby have an integrated view of the overall situation. The primary disadvantage is that they will not know the intricacies of the new release of the solution, hence the need to include development team members.
  2. Separate release team. Larger organizations will often have an explicit release management team, often a subgroup of their operations department. The advantages of a separate team include the ability to grow expertise in release management, familiarity with your production environment, and the ability to manage releases in an integrated manner. The disadvantages are the lack of familiarity with solution(s) being released and the potential to inject overhead into the overall release process.
  3. Delivery team led. This approach is common in very small organizations that do not have separate operations teams and in organizations delivery teams have adopted at very disciplined approach to DevOps that supports the practice of continuous deployment. The advantages of a delivery team approach are that that team is very familiar with how the solution is built and they are given greater flexibility to deploy as needed into production. The disadvantages are that there is a risk of deployment collisions in multi-team environments and integration problems in production between disparate systems. Luckily these disadvantages can be addressed via a combination of development-oriented DevOps practices and the following release management practices.

5 thoughts on “DevOps: Strategies for Organizing Release Management

  1. DoubleDuce

    A client struggles with release management in a consistent, repeatable manner. This is a nice framework to focus our attention on outcomes rather than the problems

  2. scottwambler

    Thanks. The DAD goal-based approach helps to make your options clear as well as provides guidance to help you choose the appropriate strategy for the situation that you find yourself in.

  3. David Shapiro

    We follow pretty closely to the “release train” model for releasing software. We continue to struggle with the pros and cons of continuous integration. The complexity of our software modules, the level of separation (or not) of the dependencies, the synchronization of transitions across teams, as well as the inadequacy of our unit tests as well as test automation – all holding us back from effective continuous integration. But, with all these inadequacies, we (I) still believe we can benefit from “more continuous” integration – even if not fully ideal. We need a practical compromise while we continue to transform. We need to reduce integration risk by eliminating code merges between branches. We need to lower the gates on check-ins that currently cause delays and elongate transitions. We may not have the luxury of switching tools during this time period. I am looking for examples of practical solutions while we are transforming… I am extremely creative on an “extremely” low budget – I really do need a push in the right direction. Can you advise…?

  4. Scott Ambler Post author

    The issues that you list regarding moving towards CI are all too common in firms with a significant legacy code base. It’s not what you want to hear, but you need to keep chipping away at the problems until they disappear. Takes a significant investment in time and money, but it’s worth it in the long run.

    Eliminating code merges between branches, as you indicate, is critical. The overhead that results from several branches can be really nasty, which it sounds like you’re living right now.

    As with my response to the other comment you posted, I think your best bet is to get a discussion going in the DAD LinkedIn forum.


Leave a Reply

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