The first thing that comes to mind about release management is how frequently releases are made and their levels, i.e. full release or patches. A common understanding of Release Management is that it is the management of introducing controlled items into a production (live) environment. But in reality release management is much more than this. “Release management is the process of planning, building, testing and deploying hardware and software, the version control and storage of software.” (British Educational Communications and Technology Agency, release management, Retrieved from http://www.becta.org.uk/tsas/index.cfm?refsect=ntss&bcsect=default§=release&id=tt5281 ) release management is not just what goes into production but also how something goes into production. It is the complete management of your production environment.
Many companies have setup a release schedule listing when pre-determined groups of changes need to go to production and put a version control tool in the backend to version all these software changes. Although this is a step in the right direction, it is not complete release management. Release management is built around a complete process that starts from versioning all the software changes (Change Management), having controlled builds (Build Management), complete system test and authorized deployment to production (Deployment) and tracking all the incidents (any unexpected event taking place to the production environment or any required change that should alter production environment) (Incident Management). Having this complete process implemented that tracks and controls what goes to production constitutes true Release Management.
Why is Release Management Important?
Implementing true release management results in two business benefits, reduction in overall cost and improved customer satisfaction. With proper life cycle management that integrates defect tracking, builds, source code version control, testing and deployment would result in a better managed application where the company can focus on continuous product improvement and not reactive product maintenance.
The other drivers for release management are listed below:
This is the main goal of release management. In its proper form, it ensures that a consistent process is followed to deploy builds into controlled environments. With repeatability comes the opportunity for continuous improvements, where issues can be identified, addressed and fixed. Repeatability also leads to higher predictability of meeting schedules with consistent releases.
Release Management includes version control of the actual source changes and tracing these source changes to the executables that are to run in production. With traceability comes reduction in application downtime as the right versions are used in production deployment and issues can be traced back to the correct version for an immediate fix.
With release management in place all the changes going to production will have controls around it to ensure that only verified code pertinent to the approved changes will be migrated with no extraneous elements that can corrupt the release. Back out procedures are readily available, in the event of a problem that requires rollback.
Thorough tests of controlled builds provide the necessary validation prior to migration. Only those changes that have passed the required test cases would move forward in the release management process and end up in the production environment thus resulting in less production problems and more up time.
All the activity involved in releasing a change to production is tracked and reported in the release management process. This provides a complete history of the people and activities involved e.g. persons who modified code elements, approved code changes, tested code changes and deployed code changes to Production. With strict government rules and regulations like Sarbanes-Oxley, this is a requirement for most organizations.
http://www.becta.org.uk/tsas/index.cfm?refsect=ntss&bcsect=default§=release&id=tt5281 ). New tools would require administrators to manage these applications. Lastly implementing a release management process is not an overnight task as it would require time and resources.
However on the flip side if you compare the value of the benefits received, such as the amount of time saved in rolling back changes, reducing the number of release related issues, complete audit trail reduces time spent on tracing the bug back to the source, and less production issues due to proper, then release management will easily pay for itself.
End To End Release Management
Now that the importance of release management is clear, the next big question is, where do you start? How can you implement this in your organization?
The iterative method of implementation is the most effective