According to varying sources, release management is everything: from just a final and formal support step in a software development lifecycle process, to the second coming of all things software engineering. It is niether of these things.

Release management does four basic things:

1. akes some existing code for a software application or program from somewhere
2. builds the code into a test environment
3. facilitates testing the code
4. puts the code into production

These four things show that release management is an integral step throughout the software development lifecycle. Along the way, a mature release management process will record what happened throughout each of these steps so a manager can see how each of the events has transpired.

Everyone creating software has some form of release management process, good or bad. It can be as simple as a developer writing some code, compiling it, then releasing it to a computer where it can be accessed without any other controls in place. While this can arguably be unhealthy, it is still a form of a release management.

At the end of any given release, assuming most of the steps were recorded, a full report of the changes, what they entailed, what testing was done to them, who released them, and when they were released can be provided. This becomes more important in more strictly audited software environments where an account of changes in production must be fully illustrated. Without a basic release process in place, providing such a record is nearly impossible.

Release management is not a checkpoint, nor is it the end-all, be-all correction to bad development practice when it comes to releasing needed changes into production. The better the process governing software changes, the better those changes can be managed. The better changes can be managed, the better quality those changes will have. Quality of software solutions is the end-goal and the real reason release management process exists.

Source: TechRepublic