Introduction #
This document defines the procedure for managing all IT Changes and Releases. A Change is defined as the addition, modification, or removal of anything that could have a direct or indirect effect on IT services. A Release is a collection of one or more changes that are built, tested, and deployed together. The purpose of this procedure is to ensure that all changes are performed in a controlled manner, minimizing the risk of disruptions, and that releases are deployed successfully.
1. Change Management #
1.1 Types of Changes #
Changes are classified into three main types based on their urgency, risk, and impact.
- Standard Change: A pre-approved, low-risk change that is performed frequently and has a documented procedure. These changes do not require a separate review or approval for each instance.
- Example: A password reset, a new user account creation, or a standard software patch.
- Normal Change: A planned change that requires review, assessment, and approval before implementation. These changes follow the full change management workflow.
- Example: A major application upgrade, a new server installation, or a firewall rule change.
- Emergency Change: A change that must be implemented as soon as possible to restore a critical service or to address a high-priority security vulnerability. These changes bypass standard review and approval processes to save time, but a post-implementation review is mandatory.
- Example: A critical security patch to prevent a cyber attack or a hotfix for a service-critical application failure.
1.2 Procedure Steps #
The following steps outline the workflow for a Normal Change. Standard and Emergency Changes have a modified workflow to fit their purpose.
- Change Request (CR) Submission:
- The change requester submits a formal Change Request (CR) through the designated ticketing system.
- The CR must include a detailed description of the change, the reason for the change, a back-out plan, a list of affected services, and an implementation schedule.
- Review and Assessment:
- The Change Manager reviews the CR to ensure it is complete and accurate.
- The CR is then assessed for its potential impact on business services, risk level, and resource requirements.
- Change Advisory Board (CAB) Approval:
- For Normal Changes, the CR is presented to the Change Advisory Board (CAB) for review and approval.
- The CAB, composed of key stakeholders from IT and business teams, collectively decides to approve, defer, or reject the change based on the assessment.
- Implementation:
- Once approved, the change is implemented according to the schedule and plan outlined in the CR.
- All implementation steps must be documented.
- Post-Implementation Review (PIR):
- After the change is implemented, a PIR is conducted to evaluate its success.
- The PIR assesses if the change achieved its objectives, if there were any unexpected issues, and if the back-out plan was successful if needed.
- The findings are documented and used for continual process improvement.
2. Release Management #
Release Management is the process of planning, scheduling, and controlling the movement of releases from the development and testing environments to the live environment. The goal is to ensure that the integrity of the live environment is protected and that the correct components are released.
2.1 Procedure Steps #
- Release Planning:
- The Release Manager, in conjunction with the Change Manager and project teams, defines the scope, schedule, and resources for the release.
- A formal Release Plan is created, which details the changes to be included and the deployment strategy.
- Release Build and Test:
- The new or changed components are built into a complete release package.
- The release package is thoroughly tested in a non-production environment (e.g., staging, QA) to ensure it is stable and meets all requirements.
- Deployment:
- The approved and tested release is deployed to the live environment according to a detailed deployment plan.
- This step often involves a pre-deployment check, the actual deployment, and a post-deployment verification.
- Post-Release Review:
- Following the deployment, a review is conducted to assess its success, identify lessons learned, and document any issues encountered.
- This feedback is used to improve future release processes.
3. Roles and Responsibilities #
- Change Requester: The individual who initiates the change by submitting a CR.
- Change Manager: Manages the change process and coordinates with the CAB.
- Change Advisory Board (CAB): A group of key stakeholders who review and approve or reject Normal Changes.
- Release Manager: Manages the release process, coordinates with all relevant teams, and ensures the successful deployment of releases.
- Implementer/Deployment Team: The technical team responsible for executing the change or deploying the release.
