Release Management

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:

Repeatability:

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.

Traceability:

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.

Controlled Deployments:

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.

Validation:

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.

Audit:

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.

Cost:

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 way to build release management, as shown above. When starting with small improvements in change management that are supported by other improvements in related areas, the organization can gradually mature into a process that works in its environment.

Before any process can be started it is critical to determine the business drivers. Determining these drivers and their priority will require inputs and consensus from all the stakeholders.

After prioritizing the business drivers, the next step is to determine what kind of processes can adequately support them. For each process, define the set of activities and roles and responsibilities.

Release Management is based on four main blocks of functionalities, Change Management, Build Management, Deployment and Incident Management. The process outlined below implements release management by iteratively increasing the capabilities and interactions of these four blocks. In addition, having dynamic reports based on the captured data would lead to continuous improvements of the release management process.

For release management to function there must be complete control over the required assets. This is done by implementing the first block called Change Management. The first iteration of change management should be to implement a Version Control tool that is process-aware so that changes are tracked and managed. The tool must support the definition and enforcement of varying levels of access permissions, as required by the roles. Version Control provides the means to track the actual source changes so that any issues after a release can easily be traced and fixed. Version control is the core of release management, thus implementing a version control tool in the first iteration of change management is necessary. The second iteration of change management should be to enhance the version control tool to be a complete process oriented change management system. With each iteration of setting up and improving release management, change management block would be taken to the next level of enhancement.

How many times have we seen that when a Production problem arises then no one knows which version of the source was used to create the executable that is running in production? Build Management will provide the direct relationship between source and executable and ensure that only tested executable make it to the production environment. Build Management is where all the source changes would be built and tested thus making it the next essential block in the release management process. The first iteration of build management would be to setup a controlled build process. The second iteration would be to automate the build process so that build would be created on demand by the change management process. Each iteration of release management would result in enhancing the build management block to be automated and integrated with the other blocks of release management.

Formalizing the process to deploy the executables to production and rolling them back if necessary should be the next block in the release management process. The first iteration of setting up deployment would be to have a formal process in place. The subsequent iterations should result in complete iteration between build management and incident management where controlled builds are automatically setup for deployment and any issues related to deployment should result in opening an incident report in incident management. Iterative deployment process ensures that there is repeatability which will lead to predictability with consistent releases.

If deploying changes to production is the end of the release management process then tracking each incident (Incident Management) has to be the start of the process. Tracking each incident helps determining the impact each release will have on production. The number of incidents and their fix would also determine the amount of work required for the next release. And finally tracking each incident will help in lowering the time wasted on redundant issues. Thus Incident Management should be the last block in release management. The first iteration of incident management would be to ensure all incidents are tracked. The second iteration of incident management would be to integrate incident management with change management so that all approved incidents can be tracked with the actual development activities.

An iterative approach to building a release management process provides a method where companies can mitigate the risk involved in large process-reengineering projects. It is rare that a perfect release management process would be implemented in first try. The first iteration of each step should result in having the correct processes and tools in place, such as version control and build tools. The second iteration should result in interaction and integration between the processes and tools, such as the version control tool automatically creating new builds as necessary. Successful implementations are those that are done in phases where each phase is an iteration and each iteration is implemented on the success of the previous.

Tracking and capturing all the data with no means to report on the gathered data is nothing more than just garbage collection. There has to be audit reports created on the modifications, approvals, testing and deployment activities to ensure that any exceptions are identified and resolved. There has to be management reports on current statuses to help predict future release information. And finally, there has to be release reports that would list the content in each deployment, its impact and any issues encountered during or after the release. Setting up a management portal with dynamic reports will help in continuous monitoring. Continuous monitoring will help the company determine the pain spots in the process and resolve them before they spread like a virus in the system.

Conclusion

Release management is a critical part of today’s software development, but is not something that can be implemented overnight. It is important that organizations understand the benefits it can provide and accordingly implement the process from start to finish. By following the approach of iteratively increasing capabilities in the four major blocks of release management, organizations can ramp up their nascent release processes to a fully fledged release management system.

Vibhav Mehrotra is a Principal Architect working for Computer Associates with strong background in software change management. He has 10 years of experience in designing and implementing several software change management solutions for various companies. Vibhav holds a Masters in Business Administration, Bachelors in Computer Science and Associates in Computer Science. In addition, he is Information Technology Infrastructure Library (ITIL) foundation level certified. You can contact Vibhav at [email protected].