Document control
Table of contents
Overview and scope
This procedure describes the lifecycle of normal changes affecting (either directly or indirectly) the EGI-branded services listed within the EGI Service Catalogue as well as the transition of all major changes and new services coming from SPM. This procedure includes registering, assessing, approving and reviewing Change Requests (CRs) as well as planning and implementation of approved changes into production.
The tool for managing the lifecycle of CRs is Jira. This supports the entire lifecycle of change requests from registering to the historical searching of CRs.
Definitions
Please refer to the EGI Glossary for the definitions of the terms used in this procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Emergency change
A change that must be introduced as soon as possible to resolve a Major Incident or to implement a security patch.
Standard change
A recurrent, well-known change that has been proceduralised to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authorisation by the CAB is effectively given in advance of implementation.
Normal change
A type of change that is neither an Emergency change nor a Standard change.
Entities involved in the procedure
- Change Requester (CR): The person who requests the change, wants it to happen, and is following it through from initial planning to implementation and review.
- Change and Release Owner (CRO): The person in charge of the change and release, following it through from initial planning to implementation and review. Initiates the Release procedure by marking a ChaRDM ticket as ready to be released, and controls and coordinates the activities in the lifecycle of a specific release.
- ChaRDM Staff: Support the Change and Release Owner over all the process, and may provide further people for testing the service or service component. Usually, it is the SDIS team.
- CRM Staff: Will be informed of the release so that they can interface with customers if needs be.
- NOC-Managers: Are informed regarding the release of the new service or service component and may provide further people for testing it.
- Testers: Optional additional testers that are informed about the release and can test and provide feedback during the testing phase.
- Service Supplier: Team responsible for the actual development, release, and deployment of the service or service component.
- CAB: Change Advisory Board is a group of technical and strategic experts (membership decided by SSB) who are tasked with reviewing proposed change requests and reviewing them and approving or rejecting the changes.
Triggers
The process is triggered when a new change is determined to be high risk or otherwise would benefit from the ChaRDM process. At this point, the Change Request is recorded in a Jira ticket.
Normal change workflow
In case the release has to be canceled at any point in time, the procedure continues at step 17.
Step | Responsible | Action | Comment | Prerequisites, if any |
1 | Change Requester | Creation of a Change Request (CR) ticket in Jira | A new ticket is created in Jira. The CR ticket consists of providing information for standard questions asking about which service is affected, the type of change, testing that has been carried out and potential impact if the change is unsuccessful, in addition to rollback plans (if possible). This helps with the review of the change by the CAB. The Normal type of change should be selected. | |
2 | Change Requester | The risk level is calculated and added to the CR ticket | Risk results from the Impact and Likelihood of the change going wrong. These values are defined in the ChaRDM Risks. Calculation of risk is done by the potential Impact (value of 1-4) multiplied by the Likelihood (value of 1-4) of the change going wrong in the Jira ticket. While considering risks, the impact of each change should be considered on service delivery, customers, users and other interested parties, policies and plans, capacity, service availability and continuity, information security, other services, and current requests for change as well as the releases and plans for deployment. | |
3 | ChaRDM staff | The Jira ticket is assigned to the Change and Release Owner who checks the change and validates the risk assessment. | ||
4 | CAB (including the Change and Release Owner) | Changes
are reviewed for approval Assessment according to the ChaRDM Change management policy is conducted and decision made whether the change should lead to an update to the service portfolio. | The CAB meets, either regularly or on an ad-hoc basis in response to an important change, to review the CR. At the CAB meeting, the Change Requester attends to answer any questions or provide clarification about the change. If the CAB is satisfied that the CR has been adequately prepared, approval is granted and recorded in Jira. | |
| 5 | ChaRDM staff | Trigger SPM.PR.01 Manage major change to service procedure (access currently limited). | When the change affects the service portfolio e.g. major new features, or changes to the status of a service (from beta to production) | Only if change is considered with a high risk to impact the business outcome of the EGI Federation |
6 | ChaRDM staff | If change is not granted approval, procedure terminates here --- | ||
7 | Change and Release Owner ChaRDM staff | Ensures that the Jira ticket contains the following information, and interacts with the Service Supplier to collect it:
The suggested duration of the test phase is usually two weeks. This information is also meant to capture the CI baseline. | Information marked as optional relates to the testing phase and is provided only when the Service Supplier requests extensive testing of the release. Otherwise it is considered that the Service Supplier conducted all testing internally prior to the Change Request with a satisfactory outcome. | Change has been accepted to be implemented as a normal release |
8 | Service Supplier ChaRDM staff | Creates a GGUS ticket against Operations SU, using release ticket type and to be used to collect and address feedback from NOC-Managers and external testers, containing the following information:
Records the link to the GGUS ticket into the Jira ticket. | Only if extensive testing has been requested by the Service Supplier | |
9 | Change and Release Owner ChaRDM staff |
|
| Only if extensive testing has been requested by the Service Supplier |
10 | Testers | Update the GGUS ticket with performed tests and their results. |
| Only if extensive testing has been requested by the Service Supplier |
11 | Service Supplier | Once the test phase is over updates the GGUS ticket with information about results of the overall testing phase. |
| Only if extensive testing has been requested by the Service Supplier |
12 | Change and Release Owner ChaRDM Staff | Validates that the release planning and preparation is appropriate, interacts with Service Supplier as needed and gives green light on the suitable deployment date by updating the GGUS ticket and the Jira ticket. | GGUS ticket - only if it was created during the extensive testing | |
13 | Service Supplier | Registers a downtime for the service in GOCDB, using 'at risk' if no downtime is expected. | ||
14 | Change and Release Owner ChaRDM staff |
| NOC-Managers - only if they have not been informed at step 9 | |
15 | Service Supplier | Deploys the release during the time slot recorded in GOCDB. |
| |
16 | Change and Release Owner ChaRDM staff | If the release took place, waits for a week to have more understanding about the release behaviour. Closes the GGUS ticket (if it has been opened) Comments the Jira ticket to provide feedback about the release. |
| |
17 | CAB | The CAB meets, pending changes are reviewed, updating the Jira CR ticket, and closed. The CAB meeting should be recorded in Indico, with minutes recording the attendees, the tickets updated and any other discussions. | Once the change is implemented, after a suitable period of time, the change shall undergo a post-implementation review (by adding a comment to the Jira ticket) and closed by the CAB. This review should be done using input provided by the Change and Release Owner and includes assigning the quality of the change to the Jira ticket (see Quality of Change). The implementation date of the change should be verified, and updated if it was different from the planned date. Finally, the Jira ticket corresponding to the change is then closed, but still searchable for future reference. |
Schedule of changes
All changes that have a CR associated with them, both past and planned, are listed in Jira. As such, it is possible to obtain a list of when past changes were carried out, as well as obtaining a list of future changes along with their planned dates, by inspecting the list of current changes in Jira.