In fact, many IT careers have been preserved by defending the idea that RM cannot be mastered by a single IT manager and, in any case, the requirements of software development and infrastructure are so distinct that they merit different treatment. This "separatism" is the single greatest factor hampering RM implementations and it is a profoundly mistaken notion.

Articles touching on the many benefits of Release Management occasionally appear, but their focus is almost exclusively on the technique of bundling application modifications together and almost never on the complete scope of the ITIL process, which goes well beyond the confines of software development and the deployment of code from QA to pre-Production environments.

In its full expression, Release Management can be a complex topic, so any attempt to cover it in a single article would be a mistake. This article will provide a “lay of the land” in terms of common day practices and some insight on what makes a good ITIL based Release Management process function effectively. In writing this article the author assumes the reader has a basic understanding of the related IT Service Support process Configuration, Change, Incident, and Problem Management. The remainder of this article will fill in the details about the usage and adoption of Release Management for enterprise organizations.

Basic Flow of Release Management

Figure 1 below outlines the basic steps that constitute a “Release Management” process. In this diagram the movement of a Release from left to right depicts progress through various environments (Development, QA and Production), each of which is a distinctive operating environment that progressively seeks to replicate Production conditions and functions separately from the other although they leverage common methods for promoting a Release between them.

It is important to note that Figure 1 below does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.