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