Is Release Management Dead?

When it comes to any form of computer technology, there are two types of death. First, there is what we could call the Monty Python definition. According to this definition, computer technologies are, like the Parrot in the famous sketch, long dead; but those invested in it are in deep denial. The second definition is the Mark Twain definition. To paraphrase the famous quote that is attributed to the author, the report of release management’s death are greatly exaggerated. This article argues that release management is far from dead, and is now more important than ever. In order to understand why, we look at the reasons why release management is assumed to be dead, what the terms “release” and “release management” actually mean, and show you what an effective release management process looks like.

The Death of Release Management

Anybody who has worked in any part of the computer industry knows that no technology ever dies.

Take mainframes as an example. Since the PC revolution took off in the late 1970s we have all been waiting for the final demise of big iron, and their biggest manufacturer, IBM. Well, guess what, mainframe are still in demand, and IBM is selling more of them than ever.

Or, how about Windows XP? It not only looks worse than it did back in 2001, it’s also full of unpatched security holes. You might think that the only people running XP are your elderly relatives, but big organizations from the UK’s National Health Service, to the US Military, and possibly your bank are still dependent on it.

Just like mainframes, Windows XP, Cobol, PHP, to name a few, many in the computer industry, especially in software development, consider release management to be dead—like the waterfall development, the Rational Unified Process (RUP), and Application Lifecycle Management (ALM)—it belonged to the dark ages before agile and CI/CD. In other words, they see it as if agile killed release management.

Release management also suffered from the same problems these other methodologies suffered from: release management was a complex, multistage process that was expensive and time-consuming. The process was linear meaning that information only flowed in one direction. Take for example building an application. Once it moved from testing in the pre-release stage, and you discovered a problem, you would not be able to move the application back into testing. Keeping the cumbersome process on track meant centralizing decision-making and management in the hands of the corporate bureaucracy.

Release management might have died a natural death, but its demise was hastened by a number of developments. The first of these was the rise of the agile movement. Agile development, in its various forms, promoted building software in short iterations and frequent releases. In parallel, the growing popularity of the web and the emergence of web apps changed previously understood ideas regarding the release process. A website is just a collection of text files that do different jobs. So, releasing a new web app comes down to copying files to a folder and making that folder accessible to the outside world.

More recently a combination of DevOps and the Continuous Integration/Delivery/Deployment (CI/CD) have probably hammered in the final nail in the Release Management coffin. DevOps merges the tasks and responsibilities for development and operations into a single role, and much of what DevOps practitioners do is related to the process of building and deploying software, so they are in control of the process. A major part of DevOps is automating the build process using CI/CD systems. Since a CI/CD pipeline automates the entire process all a development team needs to do is write software, and the machines should take care of everything else.

As any fan of dystopian science fiction knows, putting machines like Closus, Hal 9000, and SkyNet in charge will only lead to disaster. As humans we might want to believe that we can hand over everything that is boring or difficult to the machines, but that causes bigger problems. Our growing dependence on build automation, might not lead to judgement day, but there are good reasons why humans still need to be involved in release management and agile development.

What is a Release

Before this article can argue that release management is far from dead, we need to define what we mean by both release and release management. One of the reasons why people assume release management is dead is that the term release has become too broadly defined. When Windows 95 was released, computer software came in a box that contained the installation media (floppy disks, CDs, or various forms of tapes), and a large pile of documents that nobody ever read. Back then, releasing commercial software was more than just adding a link to a website or uploading a package to an app store.

Part of the problem is that the term release has come to mean different things based on whether or not you are responsible for creating the final product. We will define this as the internal definition. A release means something completely different if you are a user and/or a customer of the same product. An internal release has many different and contradictory meanings. The term could refer to a scheduled event, marked by an arbitrary calendar date, such as a limited feature rollout. Alternatively, a release could refer to a process stage, such as moving the software from the staging to the production environment. The understanding of what a release is and what it involves also varies according to your role within an organization and how the organization is structured.

Even in today’s world, and external release has a more precise meaning than an internal release. An external release is one that launches a new product, rolls out new features or fixes to an existing product, or replaces the existing version of the product with a new, and hopefully improved one. The key difference is the support activities required to deploy and maintain the product. Releasing a web app may still require provisioning new hardware, supporting software or cloud services, and relevant personnel to perform these tasks.

What is Release Management, and Why It Matters

Release management is the process that deals with major software deployments, handles the relevant tasks, assigns the required resources, across an organization. This task is often assigned to dedicated release managers. The release manager is responsible for planning and coordinating all internal and external release-related activities and devising a release management plan. The plan defines and schedules all release-related activities, as well as assigns the physical and human resources necessary to execute them.

The release management plan needs to define the necessary hardware, software, and operations needed to deploy the released software. Before the plan can be formulated, the release manager needs to identify the product’s stakeholders, and all the participants in the development, testing, release, and operational process. During the planning, implementation, delivery, and support stages of the release process, the release manager is responsible for communicating with each party and ensure they collaborate. In addition, to schedule the necessary work, the release manager will need to handle issues related to packing, internal/external dependencies, and risk management.

The reason why release management matters is that as good as a company’s CI/CD pipeline is, or how much time and effort they have invested in automating the build process, a successful release is highly dependent on the people involved. These systems are part of a much wider process that requires the involvement and engagement of all participants. Like many processes, release management requires careful monitoring and data collection, and a commitment to use this data and a dedication to continuous improvement. Over time, release management will ensure more successful releases, shorten time to market, and lower risks. As the key parts of the process are standardized and documented, they will be simplified and auditable. The organization will also benefit from improved coordination, focused on meeting its customer’s needs, and being more responsive to its operating environment.

Conclusion: Release Management Alive and Kicking

While many people may have assumed that release management was dead, it’s still alive and kicking, and more important than ever. Newer ways of creating and distributing software, such as the web, mobile, and build automation have made it possible to build and deploy software many times a day. At the same time, we have seen new methodologies, such as agile development, lean, and DevOps make it possible to take advantage of new technologies to create software faster and in ways better suited to releasing quality software. These technologies and methodologies need to be managed and coordinated. In some cases, the end result of combining agile practices with build automation ends up in releasing low-quality software to uninterested users.

In this article, we argued that release management was far from dead. Part of the reason why many assumed release management was dead was that the definition of release had become too broad. For those involved in creating software, it meant little more than a transitional stage of a project. A stage where the responsibilities for the product were transferred from one group to another. This internal definition of a release was at odds with an external release. An internal release can be completely self-contained, but an external is highly dependant on physical, virtual, and human resources. Specifically, any release is only as good as the release management plan it follows, and the release managers involved in the process.