Document control

AreaCHM / RDM
Procedure status

FINALISED

OwnerCatalin Condurache
Approvers
Approval status

APPROVAL REQUIRED

Approved version and date


Statement

The procedure describes the process to add a new product, or a new release of an existing product to the UMD repositories.

Dissemination Level

TLP:WHITE - Public

Next procedure reviewtogether with process review

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments
May 2024Alessandro PaoliniFirst draft
July - Sep 2024Catalin Condurache, Alessandro PaoliniDraft updated
Oct - Nov 2024Catalin Condurache, Alessandro Paolini, Joao PinaDraft finalised

 

Catalin ConduracheProcedure finalised

Table of contents

Overview

The procedure describes the process to add a new product, or a new release of an existing product to the UMD repositories.

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

  • Product team: The developer, or the team of developers, who is responsible for maintaining a software and producing the new releases.
  • Release manager: The representative of the Software provisioning (UMD) team
  • Beta testers

Requirements

The prerequisites are:

Triggers 

Steps for the validation of individual product releases

Note: The whole process should not last longer than 2 months without providing any information to the product team about delays through the GGUS ticket.

Step# ResponsibleActionNotes
1.1
Product teamWrites an email to URT or Submits a GGUS ticket for the "EGI Software provisioning support" support unit with the following information
  • Product release and version number
  • Link to the release notes
  • Full list of packages that compose the release and that need to be released in UMD

1.2
Release manager

Modifies the product metadata (JSON file).

Product release is injected in the EGI SW provisioning infrastructure.

This action must be completed within 5 working days after step 1.
1.3
Software provisioning team

Software validation

  • Software is tested against the QC criteria
  • If all tests are successful, the release is pushed to testing phase
  • A validation report is created and made available via the GGUS ticket
This action must start within one month after step 2 is completed.
  • If the verification does not start in one month the GGUS ticket must be updated with information about the delay.

This action must be completed in one week.

  • If the verification is not completed after one week the GGUS ticket should be updated with information about the delay. Product Team to be informed as well.
1.4
Release manager
Beta testers

Staged rollout

  • The release is tested in the production environment by beta testers

1.5
Release manager

Candidate Release preparation

  • The new release is tested against the release candidate tests
  • A Candidate Release report is created and made available via the GGUS ticket
  • If tests are successful the release is pushed to production candidate
  • If not all tests are successful, the release is rejected – procedure terminates here --
In case of rejection of a release, the GGUS ticket is updated and Product Team informed.
1.6
Release manager

Product release

  • The release is tagged as Production candidate.
  • GGUS ticket is updated and closed.


Steps for the release of UMD updates

Notes: Details of steps for preparing a new UMD release.

When a new release is ready, the UMD team should create a Change Request ticket to inform EGI Operations about the upcoming release; when the request is approved, then the new release can be announced. 

Step# ResponsibleActionNotes
2.1
Release manager

Prepare new releases making sure all documentation is properly filled.


New products that pass both the verification and stage rollout steps are ready to be deployed into production,  The products that pass those steps are added to the release branch of the dev instance: https://repository.egi.eu/software/umd/

UMD release metadata will be published in the UMD Repository and must cover the following sections:

  • Description
  • Contact Info
  • Technical Contact Info
  • Release Notes
  • Installation Notes
  • Known Issues
  • Change Log
2.2
Release managerCheck for security vulnerabilities affecting existing products

Use the Vulnerabilities Dashboard, and contact SVG (Software Vulnerability Group) about any advisories on any pending security vulnerabilities that require cross-linking

  • SVG RAT drafts advisory for a vulnerability, and notifies the Technology Provider.
  • Technology Provider confirms product version that fixes the vulnerability (e.g. BDII core 1.2.3), and the planned release (e.g. EMI-1 Update 13) in the vulnerabilities dashboard.
  • Release manager cross checks this dashboard with any planned releases.
  • The resulting list is circulated to release documentation team (TSA2.3 and TSA1.3), and the RAT manager
  • Releases CSIRT Advisories are published cross-referencing each other
2.3

Software provisioning team

Produce release candidate 

Push from dev instance to candidate (repo_sync)

https://repository.egi.eu/sw/production/umd/candidate/

2.4

Software provisioning team

Submit a Change Request (CR) to the Jira CHM to propose the new release with a list of all products

https://jira.egi.eu/projects/IMSCHM/

2.5

EGI Operations

approve/reject new release (Move ticket)

verify the list of products included and the related release notes

2.6
Software provisioning teamTest release candidateThe release candidate is automatically tested for installability and dependency problems.
  • If the test goes well the procedure goes to the next step
  • If there are problems with the release candidate the procedure goes back to step #4 or step #1 depending on the nature of the problem
2.7
Software provisioning teamDeploy release into production and change the ticket status accordinglyPost-release actions perform some housekeeping in the UMD release management area, including:
  • Update the release on the frontend (repository.egi.eu)

2.8


EGI Operations

Broadcast the UMD/CMD release announcement to the relevant stakeholders



Emergency release

Definition of emergency release

An emergency release is the process of releasing one product, or a set of product, with the targeted goal of solve a specific problem that affects the EGI infrastructure. To qualify the problem for an emergency release the problem should be classified in at least one of the following categories:

  • Major incident
  • Critical security vulnerability

Steps for emergency release

Step# ResponsibleActionNotes
3.1
Product teamSubmits a GGUS ticket for the "EGI Software provisioning support" support unit with the following information:
  • Product release and version number
  • Link to the release notes
    • Information about the problem that is patched by the release (e.g. link to GGUS ticket)
  • Full list of packages that compose the release, and that need to be released in UMD

3.2
As requestedFollow the steps of the Steps for the validation of individual product releases from step 1.2
  • For emergency releases the step 1.4 is optional. UMD team, together with the security team if relevant, will decide if the staged rollout should be skipped or not, based on the urgency of the release.

3.3
As requestedFollow the Steps for the release of a UMD updateAll the steps should be properly executed
3.4
EGI OperationsCommunicate to the relevant stakeholders the availability of the new product(s) releaseDepending on the nature of the problem solved, and on the urgency, the release manager will contact the EGI Security Vulnerability Group, or produce a broadcast to invite service managers to upgrade to the new version.