Scribd
Upload
108 views5 pages

Change Management and Release Management:: 2. Types of Changes

The document discusses change management and release management. Change management controls changes to production environments to minimize disruption, while release management plans, builds, tests and delivers capabilities in release packages. A release is a collection of related and authorized changes that are tested and released together. There are standard, minor and major changes based on impact and normal or emergency changes based on urgency. Release management complements change management by controlling the introduction of tested releases into production.

Uploaded by

Kundan Singh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
108 views5 pages

Change Management and Release Management:: 2. Types of Changes

The document discusses change management and release management. Change management controls changes to production environments to minimize disruption, while release management plans, builds, tests and delivers capabilities in release packages. A release is a collection of related and authorized changes that are tested and released together. There are standard, minor and major changes based on impact and normal or emergency changes based on urgency. Release management complements change management by controlling the introduction of tested releases into production.

Uploaded by

Kundan Singh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

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.

You might also like