Blog:

Pitfalls in release management

Published on Nov 28, 2017
By Terry / Senior System Design Engineer

I like to think of release management like bull riding: the bull representing a product, the rider being the company or developer making the product and the riding itself the process of managing the release of this product. As soon as the product is released into the field it is somewhat unpredictable what the final outcome will be.

To have a more defined outcome some strategies work better than others, it all depends on what you want to achieve with the product. After exploring what typically happens when releasing a product, some pitfalls are examined and proposals for a more manageable release are discussed.

Release management entails the entire process of coordinating the release of a (new) version of a product – this can be software, hardware, or both. As each product is unique, so will be its release. When designing a product, it is a good idea to think about how the product is going to be introduced, what the intended user group will be, how is it going to be supported, how often updates will be rolled out and how these updates will end up in the product.

Most products developed often have 2 user groups: 1 group which likes new features and updates and 1 group which does not like changes in any way: they expect the product to work, be stable and not to change with an update. This often collides as new features might cause some issues to pop up (which need a fix), or an update to the UI which changes the way the product is used. A strategy should be in place to be able to handle both cases and still allow to roll out releases whenever needed.

A release is usually planned and when it is rolled out, it will be tested. Automated, manually, or a combination of both – it represents some time spent to determine the product status. During this time the product is not to be changed (other than bug fixes), as it might require testing to be redone.

For software development: taking above into account, a versioning system which supports multiple branches will help. It can be used to represent the two user groups. The first group being a develop branch where new features are introduced. This branch is volatile, in motion and most work is performed here. Depending on the size of the product there can be additional feature branches which focus on a single feature, sometimes with sub-branches for more fine-grained introduction of these features. The other group can be represented by a master branch where the focus is on stability. This gets few updates, but they represent a large body of work. To bridge between these two branches (master and develop) a release branch is used: from the develop branch a point is chosen to start stabilizing the product (for a new release). Here the focus is on testing and bug fixing, resulting in a stable release after some time. When testing is completed the release branch is merged back to the master branch and rolled out as the new release.

A release is created by people, and good release management understands that people should support a chosen release strategy. If not it can cause a lot of friction as people will try to minimize the impact on their work – even if means to bypass to chosen strategy.

An example: people delivering features to the master branch directly, before the release is completed. It could be they are forced by their project leader to deliver a feature or that they act on their own to bypass the release strategy. The first is an error in planning, features are scheduled for a release and apparently new features are needed which are outside the scope for the planned release. Either the feature is rescheduled for a new release, or the scope of the release is reviewed. The second is a rogue action and can be averted by some disciplinary methods: some means to have the person involved support the chosen release strategy.

Another example is forcing a release, outside the scheduled release plan. This can be due to features which are promised to a customer which need to be delivered before the release is completed or when more work is needed to finish the release while the release schedule is maintained at all cost. Either way this will result in more work: things get wrapped up at the very last moment, which affects quality. Testing will result in finding more issues – or when testing effort is reduced to speed up the release process – more issues will be found after a release. This can even cause a delay for the next release to repair the damage done with the current release. For these two cases a better alternative would be to create a customer specific release (with only the features needed for that customer – in order to deliver on time), to descope the amount of work (since it cannot be completed in time for the release), or to postpone the release until all work is done.

Choosing a proper branching strategy for a product can be quite a challenge, just have a look at all the variations which have been created over time.

The topic of Release Management is very much alive and shown by the many blog articles found on the web. An example is the discussion pro and con for specific strategies, in this case: GitFlow vs OneFlow (and a Git branching model and workflow).

The thing that has been the greatest contributor for a stable release environment for me is a proper definition of the release strategy. Which model is most suited for the product, how is the support done after the product is released. This determines for a large part the branching strategy and how releases are managed.

I am interested to hear what your thoughts are on this matter, please let me know in the comments!