Skip to main content

How to prepare a stable release

· 3 min read

A debate about software release process​

In every software project there is a lot of emotional discussions about the release process, branching model, testing environments.

All that discussions usually want to answer a question: how the hell we can make a stable deployment with less stress and less bugs?

You can deploy few times a day or once a month, you can have monolithic application or microservices - it does not matter so much. You can always apply the following rules.

The rules​

  1. There was a deployment to production - put aside this version so it is easy to add hot-fixes to it in case of emergency.  Test hotfixes on a dedicated environment. Update production-like version of code after applying hotfix changes to production.
  2. Focus team efforts on preparing next release.
    • Start with merging some finished development tasks. What does it mean finished? It depends on your definition of done. It may include code review done, automated tests passing, metrics matching or just a developer changing status to "Resolved" if you can take more risk
    • Have release candidate tested in dedicated environment where QA team / release manager has the ownership when and what can be added
    • When verifying release candidate only fixes related to the tasks under tests are allowed
    • Any other tasks can be added only after the approval of people responsible for release
    • Remember that adding anything new to release candidate may destabilize the whole version and delay the release
    • Avoid reverts and cherry-picks or even forbid it allowing only for merging changes
    • Have tools to track what commits related to which tasks were added to the release candidate
    • Do not take too much validation work at once. Try to achieve stable release candidate in at most 2 weeks.
  3. When release candidate is stable and everything works as expected you can deploy immediately. If you have strict release process with fixed dates, put this version aside to be waiting for next release. You already know that your release notes won't be empty. It can be only better. Start preparing next release candidate on top of that. If it will be stable before agreed release date, again put aside a bigger version and repeat this process until your release date has come.

Process has several steps but it doesn't have to be cumbersome to follow. If your team is able to perform all the steps above automatically, within minutes or even seconds, it means that you have successful implemented continuous delivery - holy grail for release managers.

The ultimate goal - being reliable​

This process can be implemented by adopting GitFlow but this is not the only way. Ultimate goal is to be certain about every deployment to production. Without any surprising changes appearing on production and without any panic on the release day and hours after that.

The scope of the release is usually negotiable. But the trust is usually not. Reliable software teams prefer to make smaller amount of changes or introduce it later rather than risking production system being unstable.