Document control

Area
Procedure status

DRAFT

Owner
Approvers
Approval status

APPROVAL REQUIRED

Approved version and date


Statement

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








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/CMD 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.

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 RT ticket.

Step# ResponsibleActionNotes
1.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
  • Full list of packages that compose the release and that need to be released in UMD/CMD

1.2
Stage rollout managerProduct release is injected in the EGI SW provisioning infrastructure.
  • One or more RT tickets are created to track the progresses of the software provisioning of the new product release.
  • Reply to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket.
  • The RT ticket is then used to track the progress of the software in the release process.
  • The RT ticket status is now "unverified".
This action must be completed within 5 working days after step 1.
1.3
Software provisioning team, quality assuranceBegin of verification
  • Move the RT ticket created in step 2 in the "Verification" status. This means that the software provisioning team is verifying the product in the testbed.
  • Perform the verification in the testbed.
  • Attach verification report to the RT ticket.
This action must start within one month after step 2 is completed.
  • If the verification does not start in one month the RT 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 RT ticket should be updated with information about the delay and moved to the "Delayed" status. PT to be informed as well.
1.4
Staged Rollout managerBegin staged rollout
  • Move the ticket from "Verification" or "Delayed" to the "Staged rollout" status
  • The product is announced to the early adopters testing in staged rollout the product.
  • The reports provided by the early adopters are attached to the RT ticket.
This action must be completed in one month.
  • Tickets more than one month in the "Staged rollout" status must be moved to the "Delayed" status with an explanation for the delay.
1.5
Staged rollout managerComplete staged rollout.
  • Evaluate the reports and take a decision about the release.
    • If the product release qualifies for production the RT is moved to "UMDStore"
    • If the product release does not qualify for production the RT ticket is moved to "Rejected" and an explanation is provided to the developers.


Steps for the release of a UMD/CMD update

Step# ResponsibleActionNotes
2.1
EGI OperationsFreeze UMD/CMD release contentsUsing the UMD Composer add all products that are queued in the UMDStore to a new UMD/CMD release bundle.
2.2
Staged rollout managerPrepare wiki page for the release with known issues and installation notesCreate a Wiki entry for the release at:
  • UMD-x:UMD-x.y.z using the major (x), minor (y) and revision (z) numbers for UMD release,
  • CMD-OS-x:CMD-OS-x.y.z using the major (x), minor (y) and revision (z) numbers for CMD-OS release, or,
  • CMD-ONE-x:CMD-ONE-x.y.z using the major (x), minor (y) and revision (z) numbers for CMD-ONE release.

Create sections for each product that is included in the release. Add all findings (bugs, workarounds, etc.) collected in the QC Verification and Staged Rollout reports to the "Known Issues & Installation notes" wiki entry.

2.3
Staged rollout managerCheck for security vulnerabilities affecting existing productsUse the Vulnerabilities Dashboard, and contact Linda Cornwall 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.4
EGI OperationsCompile release documentation in the release web siteUMD/CMD release metadata will be published in the UMD/CMD Repository and must cover the following sections:
  • Description
  • Contact Info
  • Technical Contact Info
  • Release Notes
  • Installation Notes
  • Known Issues
  • Change Log
  • RT tickets containing requirements associated to this release if available (Added on 15 Nov 2017)
2.5
EGI OperationsProduce release candidateFrom the list of included products in (1) generate a Release Candidate. Notify quality UMD assurance team.
2.6
UMD quality assurance teamTest release candidateThe release candidate is automatically tested for installability and dependencies problems.
  • If the test goes well the procedure goes to next step
  • If there are problems with the release candidate the procedure goes back to step #6 or step #1 depending on the nature of the problem

New

2.7


Staged rollout managerSubmit a Change Request (CR) to the Jira CHM to propose  the new release

Only when all previous actions are signed off ands the UMC/CMD release is ready to be published.

The CR will include references to the new or updated products incl specific GGUS tickets (see Validation of individual product releases)

2.8
EGI OperationsPublish UMD/CMD release

Only when all previous actions are signed off, publish the UMD/CMD release.

Only when Change Request has been approved, publish the UMD/CMD release

2.9
EGI OperationsPost-release cleanupPost-release actions perform some housekeeping in the UMD/CMD release management area, including:
  • Add the UMD/CMD release announcement to UMD/CMD release schedule overview
  • Add text "EGI has released UMD 1.4.0 on 19 December 2011. (Announcement)" in the list of the topics for the next EGI monthly broadcast


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/CMD

3.2

Follow 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

Follow the Steps for the release of a UMD/CMD 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.