Document control
Procedure reviews
The following table is updated after every review of this procedure.
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:
- The product team releasing the software has already provided the information to fill the product ID Card as described in the links below:
- Development teams should follow Instructions for Technology Providers
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# | Responsible | Action | Notes | |
---|---|---|---|---|
1.1 | Product team | Submits a GGUS ticket for the "EGI Software provisioning support" support unit with the following information
| ||
1.2 | Stage rollout manager | There is no staged-rollout activity any longer. Maybe this step can be replaced with some actions undertaken by the UMD team. 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, quality assurance | Same as above. Begin of verification
| This action must start within one month after step 2 is completed.
This action must be completed in one week.
| |
1.4 |
|
| ||
1.5 |
|
Steps for the release of a UMD/CMD update
To details the new 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# | Responsible | Action | Notes | |
---|---|---|---|---|
2.1 | UMD staff | Freeze UMD/CMD release contents | Using the UMD Composer add all products that are queued in the UMDStore to a new UMD/CMD release bundle. | |
2.2 | Prepare wiki page for the release with known issues and installation notes | Create a Wiki entry for the release at:
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 | Check for security vulnerabilities affecting existing products | Use the Vulnerabilities Dashboard, and contact Linda Cornwall about any advisories on any pending security vulnerabilities that require cross-linking
| ||
2.4 | Compile release documentation in the release web site | UMD/CMD release metadata will be published in the UMD/CMD Repository and must cover the following sections:
| ||
2.5 | Produce release candidate | From the list of included products in (1) generate a Release Candidate. Notify quality UMD assurance team. | ||
2.6 | UMD quality assurance team | Test release candidate | The release candidate is automatically tested for installability and dependencies problems.
| |
New 2.7 | Submit 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 Operations | Evaluate and approve the request.
|
Only when Change Request has been approved, the UMD team can publish the UMD/CMD release | |
2.9 | UMD Staff | Post-release cleanup | Post-release actions perform some housekeeping in the UMD/CMD release management area, including:
|
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# | Responsible | Action | Notes | |
---|---|---|---|---|
3.1 | Product team | Submits a GGUS ticket for the "EGI Software provisioning support" support unit with the following information:
| ||
3.2 | Follow the steps of the Steps for the validation of individual product releases from step 1.2
| |||
3.3 | Follow the Steps for the release of a UMD/CMD update | All the steps should be properly executed | ||
3.4 | EGI Operations | Communicate to the relevant stakeholders the availability of the new product(s) release | Depending 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. |