CHANGE MANAGEMENT AND RELEASE MANAGEMENT:

1. INTRODUCTION
The Primary objective of change management is to allow the addition, deletion and modification of production CIs, with the minimum disruption to existing IT services. The primary objective of Release Management is to plan, build, test and deliver the capabilities in the form of release packages for providing the services as specified by service design. The paramount objective of both change management and release management is to protect the integrity of the production environment. The change management process usually covers the control points required for Changes to be implemented in the production environment, such as approvals and validation and does not cover release and deployment (design, build, testing, or development procedures) activities. The release and deployment process is responsible for the physical implementation of changes into the production environment after getting the approvals from the change management process.

So, we can comment that a Release Management is a complimentary process to Change Management. It controls the introduction of releases into the production environment, minimizing risk associated with the changes. A release is a collection of related, authorized changes to an information technology (IT) service, which are tested and then released into the production environment.

2. TYPES OF CHANGES:

A) BASED ON IMPACT

1. STANDARD CHANGES: This is a type of change that is frequently performed and implementation for such changes is simple and routine.Standard change tasks are tested and proven. Success of standard Changes can be determined and reported quickly. These are usually Infrastructure changes up to server layer for example configuration setting. No development is required and they are implemented directly in production. These changes can be requested anytime, approved anytime and implemented anytime. A standard change catalog is a list of changes (Along with designated approver(s) for each change) approved by CAB. A standard change catalog must be maintained by the organization for all the standard changes. The lifecycle for such changes is

1. RFC submission. 2. Approval for change management catalog. 3. Implementation by Release and Deployment Management 4. Review and Close.

2. MINOR CHANGES Minor Changes usually do not add any new element or functionality to the existing services. Technical risk control measures lies within implementing group for such changes. Most often, development or change build activities are not required for implementation of these changes. However some development or coding change may be required. These changes require testing before they can be moved into production. UAT may not be necessary. These are

typically application patches or minor bug fixes in the application usually originated from a problem. The lifecycle for such changes is

1. RFC submission 2. Technical approval 3. Testing 4. Deployment (CAB) approval 5. Implementation 6. Post Implementation Review 7. Closure

3. MAJOR CHANGE For Major Changes different levels and types of testing are usually required for implementation of these changes. Development or change build activities are usually essential for implementation of these changes. These changes require testing and UAT before they can move into production. These are application usually enhancements, major bug fixes or project. The lifecycle for such changes is

1. RFC submission 2. Build approval 3. Build 4. Testing / UAT 5. Deployment (CAB) approval 6. Implement

7. Post Implementation Review 8. Closure

. B) BASED ON URGENCY

1. NORMAL CHANGE: A change that follows all the steps of the change process. It is assessed by either a change manager or the CAB.

2. EMERGENCY CHANGE: A change that must be introduced ASAP e.g. to resolve a major incident or implement the critical security patch. ECAB is engaged for quickly provide the expert advice for emergency change decisions.

3.CHANGE AND RELEASE & DEPLOYMENT MANAGEMENT PROCESS.