Document control

Area RDM
Procedure status

FINALISED

Owner

Catalin Condurache

Approval status

APPROVED

Approved version and date

v13  

Statement

This procedure applies to regular releases of the centrally-provided production services that need to be fully built, tested and deployed.

This may be either:

  • a high risk/impact change needing careful testing
  • a set of linked changes to test and deploy together
  • lower priority changes bundled together to reduce downtime.
Dissemination Level

TLP:WHITE - Public

Overview

This procedure is meant to cover releases for which it is required to go through a complete planning/testing/deployment phase.

A Jira ticket coming from CHM is used to orchestrate the release and deployment, but in order to allow any participant to test and provide feedback during the testing phase a dedicated GGUS ticket is created.

Once the release will have been deployed the GGUS ticket will be closed, feedback will be added to the Jira ticket and re-assigned to CHM so that they can review it.

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.

Entities involved in the procedure

  • Change Owner: The person in charge of the change, following it through from initial planning to implementation and review. Initiates the Release procedure by marking a CHM ticket as ready to be released, assigning it to RDM.
  • Release Owner: The person in charge of the release, control and coordinate the activities in the lifecycle of a specific release.
  • RDM Staff: Support the 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.

  • Service Supplier: Team responsible for the actual development, release and deployment of the service or service component.

  • 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.
  • 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

CHM1 Manage changes including emergency changes

Steps

 In case the release has to be cancelled at any point in time, the last step will be triggered.
Step#ResponsibleActionPrerequisites, if any

1.

Change Owner

Updates Jira ticket assigned to CHM status to mark it as accepted for a regular release.Change has been accepted by CHM as a normal change that should be handled via a regular release.
2.RDM Staff

Appoint a Release owner, that will coordinating the release with the support of the RDM Staff.

The ticket is assigned to the Release Owner.


3.

Release Owner

RDM Staff

Ensures that the ticket contains the following information, and interacts with Service Provider 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 duration test phase;
  • Suggested deployment date;
  • Testing instance URL and testing instructions;
  • Names of testers if testing is manual (if not defined Development team may ask to appoint testers).

The suggested duration of the test phase is usually two weeks.

This information is also meant to capture the CI baseline.


4.

Service Supplier

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:

  • Name of the service or service component;
  • Date of release;
  • Release notes;
  • Updated documentation availability;
  • Suggested deployment date;
  • Testing instance URL and testing instructions;

Records the link to the GGUS ticket into the Jira ticket.


5.

Release Owner

RDM Staff

  • Informs the NOC-Managers by email about the upcoming release, pointing to the GGUS ticket and asking if there is anyone else interested in performing the test.
  • Potentially involves further people for performing the tests, referring to the link to the GGUS ticket.

6.TestersUpdate the GGUS ticket with performed tests and their results.
7.Service SupplierOnce the test phase is over updates the GGUS ticket with information about results of the overall testing phase.
8.

Release Owner

RDM 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.


9.

Release Owner

RDM Staff

Informs CRM 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.
10.

Release Owner

RDM Staff

Informs NOC-Managers  by email 10 days before the deployment.There is more than 10 days between the validation of the deployment from step 7 and the deployment in step 12.
11.

Service Supplier

Registers a downtime for the service in GOCDB, using 'at risk' if no downtime is expected.
12.Service SupplierDeploys the release.
13.

Release Owner

RDM Staff

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

Closes the GGUS ticket.

Comments the Jira ticket to provide feedback about the release.

Re-assigns the Jira ticket to Change Owner so that it can be reviewed according to CHM1.


Table of contents