It’s Friday afternoon. Do you deploy to production?
A lot of teams are afraid to push their code to production before the weekend because something might go wrong that may impact their well-earned weekend.

Today, I don’t want to dive too deep into how we can create enough confidence in each release. Instead, I want to explore the different phases of maturity when it comes down to releasing software:

  • Phase 1: Risk Management
  • Phase 2: Autonomous, continuous deployments
  • Phase 3: Managed roll-outs as a strategy

Phase 1: Risk Management

Most teams that are afraid to release on a Friday afternoon fall into this category. 

Releases are postponed while developers keep cranking out more code changes. In this situation, it’s necessary to carefully manage what is being tested and what changes belong in the release. A release manager usually manages the inherent risk of a release. They need to plan the release so that a potential outage has minimal impact on customers. The bigger the risk, the higher the chance that releases happen at crazy hours: Sunday morning, Tuesday at 4 AM It takes a long time before changes made by the development team end up in the customer’s hands, often decreasing developer motivation significantly.

Phase 2: Autonomous, continuous deployments

This is the phase that most engineers should be aiming for when they are afraid to release. The first goal should be gaining enough confidence in the quality of the code that will be released. This can be achieved through a combination of techniques like test automation, static analysis, code review, pair programming and so on. Additionally, confidence levels can be increased through releasing smaller parts more frequently (i.e. reducing risk) or by having a very quick and easy rollback procedure in case something goes wrong. In the end, the result should be that releasing becomes a no-op, a formality, something that can be automated. There is plenty of material available on Continuous Integration and Continuous Deployment and this is the essence of eliminating the need for careful release management.

Phase 3: Managed roll-outs as a strategy

Once releasing becomes trivial, we get the option to take things one step further. By decoupling deployment from feature delivery, we can keep releases flowing continuously while carefully managing what features are available to our customers (e.g. through feature flagging). At this maturity level, we can build a deliberate go-to-market strategy where we target features to certain groups of users or where we pace and group the roll-out of new features. Even though we eliminated the need for release management, we re-introduce the management of releases but with a completely different goal. We’ve grown from managing risk to managing change, value, and expectations. We’re optimizing our customers’ experiences instead of limiting the potential negative impact. This is where product teams can flourish and gain an advantage over their competitors. This should be the end goal when working towards a more effective release strategy. Getting here is not easy. It requires the counter-intuitive approach of removing all release management to gain the necessary stability.

At madewithlove, we frequently help our customers grow from one phase to the next by combining product management and software engineering. If you think we can help you bring your releases to the next level, contact us now.