Enterprise Release Management: the Top 10 Myths (part one)



At least you can never say Release Management is boring! Wherever we turn today someone is ready to deliver an absolute truth about the subject. The reality is that Release Management cannot be defined in general terms; it cannot be bounded, except by actual practitioners. There is no hard-and-fast rule about any aspect of it. Yet we are all bombarded with strictures commanding us to do, or be, some idealized version of a Release Manager.

Here are my top ten myths (five this week, five next week) that I seem to spend most of my time debunking these days.

10: One process fits all – wrong!

“We need one process for all release management!” is the guiding principle of so many organizations that are trying to implement a modern release management infrastructure. The reality is that there needs to be many processes:

  • One main, high-level process that defines the major milestones (perhaps) that we measure our progress against, the “macro milestone” process.
  • And many minor processes that accommodate the various factors that guide each development team such as its technology, time-to-market pressures, risk aversion, development methodology and project complexity, the “micro milestone” processes.
  • And let’s not forget we need an emergency process for those patches that have to be fast-tracked through the system.

9: You need one repository – wrong!

Apart from the sheer impracticality of the statement, anyone who suggests that you can only do release management if there is one repository is just not trying hard enough. Of course, having one repository is easy to say – it’s just not easy to do. Migrating all your code from the developer’s repository of choice is error-prone and usually results in unwanted compromises over things like how many revisions can be kept. Retraining the team is expensive and re-tooling the team can be prohibitively costly. What you do need is the ability to coordinate the activities of the teams, irrespective of the repository they use. You need to be able to move the code from their repository to the test areas repeatedly and automatically and safely deploy to production. You don’t need to disrupt your development organization and spend money on solutions they will resent using.

8: You need one solution from one vendor – wrong!

No one vendor has the best-in-class solution for all of your release management needs. Who has the best repository technology, the best parallel development capabilities, or the best support for Agile or DevOps? These will always be a matter for conjecture and disagreement, of taste and negotiating skills. The point is that an organization needs to select the best tool for the job and needs to make sure all vendors’ tools work together. But beware; vendor-created, point-to-point, integrations are fragile. Ensure your vendor is exposing their API’s through web-services and that their integrations support your process, not their own.

7: Project status meetings are essential – wrong!

Project meetings are a monstrous waste of time and resources. One customer describes the weekly release meeting as their “million dollar meeting” as it requires 70 members of staff, including several very senior members, to be in attendance for more than 4 hours. Each person gets to speak but it is often little more than “I’m good.” Imagine the time and money that can be saved by eliminating meetings alone through the use of a good process-centric workflow tool that guides everyone on the team through their part of the overall process. Status meetings can now become about exceptions and only involve the stakeholders who are impacted by those exceptions. So, when you get a meeting invitation, we encourage you to just say ‘Decline.’

6 (and a biggy to end this week’s list): Release management is just about deploying the code – wrong!

Well, actually, that is called “deployment.” Release management has many definitions with regards to the scope of the lifecycle that it covers. One useful definition says that release management begins when the release is given a name and ends when the name is no longer used. For example “the fall marketing release” might start in planning long before any code is checked out or worked upon. Nonetheless, it now needs to be tracked, deployment windows identified in the calendar, the resources applied and so on. Whatever your definition of release management, your infrastructure should support your lifecycle from when you define the start point to where you define the end point. Don’t be sucked into some vendor’s definition.

Next week we will look at some more infamous myths about this most critical of topics.

Share this post:

Leave a Reply

Your email address will not be published.