Document control

Procedure status

DRAFT

Approvers

Process Owner 

OMB

Approval status

NOT APPROVED

Approved version and date

v. 13 (version to be made available under ChaRDM3 Manage standard change workflows under DRAFT - EGI Change and Release Deployment Management ChaRDM)

Statement

Procedure documenting how a standard change is registered and approved before release deployment and reviewed after implementation.

This procedure applies to individual low risk/impact change and provides steps for service updates and releases of the centrally-provided production services.

Dissemination Level

TLP:WHITE - Public

Table of contents

Overview and scope

This procedure describes the lifecycle of standard changes affecting (either directly or indirectly) the EGI-branded services listed within the EGI Service Catalogue. It covers the managing, planning and implementation of pre-approved or 'standard' Change Requests into production.

The list of pre-approved or 'standard' Change Requests (CRs) for service shall be created and maintained in the list of Standard changes. Its existence shall be made known to all operational staff for the service.

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.

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.

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 service or service component.

  • 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 features in the list of pre-approved or 'standard' CRs for a specific service (Standard changes). At this point, the Change Request is recorded in a Jira ticket.

Standard change workflow

A Standard Change is a recurrent, well-known change that has been previously submitted and approved by the CAB as a normal change (see ChaRDM2). Managing the list of standard changes (and further information about suitable changes that may be considered as candidates for standard changes) is described in ChaRDM.PR.04 Manage the list, descriptions and step-by-step workflows for well-known and recurring changes. The workflow when implementing standard changes is as follows:

In case the release has to be canceled at any point in time, the procedure resumes at step 8.


Step

Responsible

Action

Comment

Prerequisites, if any

1

Change Requester

Creation of a Change Request (CR) ticket in Jira and marking it as a Standard Change, referring it to the name of the change as listed in the wiki

A new ticket is created in the Jira queue corresponding to the correct service, with the planned date of the change. A completed Change Request document is not required for Standard Changes.

The proposed change is documented in the list of Standard changes

2

ChaRDM staff

The ticket is assigned to Change and Release Owner who checks the change request



3

Change and Release Owner

The change is considered and either approved or rejected.  If it is rejected, the procedure terminates here ---

This can be done by discussions between the Service Supplier and the Change and Release Owner. If necessary, details of the discussion can be added to the Jira ticket.


4

Change and Release Owner

ChaRDM staff

Ensures that the Jira ticket contains the following information, and interacts with Service Supplier to collect it:

  • Name of the service or service component;
  • Date of release;
  • Current version of the service;
  • Version of the service to be released;
  • Release notes;
  • Rollback procedure;
  • Updated documentation availability;
  • Suggested deployment date;

This information is also meant to capture the CI baseline.

Gives green light by updating the ticket.

 

Change has been accepted to be implemented as a standard release

5

Service Supplier

Registers a downtime for the service in GOCDB, using 'at risk' if no downtime is expected.

 

 

6

Change and Release Owner

ChaRDM staff

  • Informs the NOC-Managers (noc-managers [AT] mailman.egi.eu) by email about the release and affected service or service component
  • Informs CRM Staff about the release by sending a mail to ucst [AT] egi.eu and providing a link to the Jira ticket so that they can provide feedback if needed.

 

 

7

Service Supplier

Deploys the release during the time slot recorded in GOCDB.

 

 

8

Change and Release Owner

ChaRDM staff

 

If the release took place, waits for a week to have more understanding about the release behaviour.

Comments the Jira ticket to provide feedback about the release.

 

 

 

9

CAB

The change is 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.

If the change was not successful, the change should be removed from the list of Standard Changes, and any subsequent change similar to it should be submitted as a Normal Change in the usual way (see ChaRDM.PR.02).


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.