In the previous blog, you read about the following:

An introduction to Enterprise Release Management (ERM), Identifying stakeholders, release strategy, approaches, and determining readiness for release.

This blog will showcase how ERM integrates with other processes.

ERM integration with other processes

Enterprise Release Management (ERM) is a discipline that is well integrated with other ITIL processes. It closely works with Change Management, Configuration Management, and Incident & Problem Management processes to provide a centralized enterprise-level function. The sections below will explain these processes in detail.

Change Management

Change Management process is tightly integrated with Release Management. It is a process where a change request gets reviewed and authorized by an authorizing body. Release Management goes in parallel with Change Management, which includes planning how these changes would be built, tested, and finally deployed into production.

For example, for any type of enhancement or bug fixes, a change request would be raised by the development team. After passing all quality checks, Change Approval Board (CAB) approves them. Release Manager receives the approved Change Requests for releasing the same during production.

Change Management is more of an authorization process, whereas Release Management is about implementing those authorized changes. During Change Management, one or more changes would be released at the same time. The change management process will be more proactive & predictable along with Release Management, as it helps in managing the volume of change.

Finally, Release Manager provides information on the release & deployment status (successful/failed) to all stakeholders, inclusive the development team.

There are three types of changes: Standard, Normal, and Emergency.

Standard: These types of changes are pre-authorized, where there is a low risk, and no CAB approval is needed. For example, scheduled operational changes.

Normal: This type of change goes through the CAB approval process, where it is analyzed for risk and impact. For example, any feature promotion.

Emergency: This type of change is done when there is a need to fix any major incident. This change does not go through the complete life cycle of the Change Request.

Incident Management

An incident is any unplanned breakage at the time of production, due to which there is an interruption in the service. It can be major or minor, or severity either 1 or 4, which will be addressed by the support team. Incident Management is about identifying, analyzing, and finally resolving the reported incidents.

The support team validates the severity and priority of every incident reported by an end user. Based on the validation, the release would be planned. For example, if there is a minor incident with low severity and priority, it can be released with the next upcoming minor release. But if it is a major incident with low severity and priority, it can be an emergency release.  The release schedule is determined by the severity of the incident. It could also result in an emergency change deployment.

Release Manager receives information about all the incidents that need to be part of the upcoming release. He will then coordinate with various teams to know the status of those incidents, which is required for planning during the release. In this process, the decision on the type of incidents that goes through the Change Management process is also identified.

The operations team updates the training document with the incident fixes details, which is referred to while troubleshooting similar incidents. Finally, the Release Manager provides information on the release status (successful / failed) to all stakeholders, including the operation team.

Problem Management

Problem Management is a process that helps in identifying a recurring issue, analyzing it, and finding the root cause before fixing it. Problem management can be either reactive or proactive. In a reactive situation, the issue would be based on similar situations or pattern, which is analyzed and fixed. In a proactive situation, errors are identified before the incident occurs.

The release manager receives the information on the fix, and with the help of Release Management and the Change Management process, he ensures that the problem gets fixed in parallel to the release.

The outcome of this update is entered in Known Error Database, which can be referred to for resolving similar issues in the future.

Configuration Management

Configuration Management is a process for maintaining the system/product/application in a desired state. It is done by consistently defining settings and maintaining them as per the established baselines. The baseline configuration gives visibility to any configuration modifications, enabling audit trails and tracking of every change made to the system.

During the release, Configuration Manager collects the configuration data from various teams and baselines it for the benefit of the operations team. The baselined configuration is stored as a part of version control, and the release manager uses the baselined version during every release for impact analysis.

All ITIL processes are interdependent on each other and provide empowerment to the ERM process.

The next blog would give you insights into how ERM works with DevOps.