Difference between revisions of "PROC25"

From EGIWiki
Jump to: navigation, search
(Step for the release of a UMD/CMD update)
(Step for the release of a UMD/CMD update)
Line 137: Line 137:
 
*Known Issues
 
*Known Issues
 
*Change Log  
 
*Change Log  
 +
* RT tickets containing requirements associated to this release if available (''Added on 15 Nov 2017'')
 
|-
 
|-
 
|2.5
 
|2.5

Revision as of 17:37, 15 November 2017

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


Documentation menu: Home Manuals Procedures Training Other Contact For: VO managers Administrators



Title Middleware release procedure
Document link https://wiki.egi.eu/wiki/PROC25
Last modified 0.1
Policy Group Acronym OMB
Policy Group Name Operations Management Board
Contact Group operations at egi.eu
Document Status DRAFT
Approved Date
Procedure Statement The procedure describes the process of adding a new product release to the software provisioning process and releasing it in UMD/CMD.
Owner Owner of procedure


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:

Steps for the validation of individual product releases


Responsible Action Notes
1.1 Product team 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/CMD
1.2 Stage rollout manager Product 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 assurance Begin 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 manager Begin 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 manager Complete 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.

Notes

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


Responsible Action Notes
2.1 EGI Operations 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 Staged rollout manager Prepare wiki page for the release with known issues and installation notes Create 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 manager 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
  • 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 Operations 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:
  • 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 Operations 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.
  • 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
2.7 EGI Operations Publish UMD/CMD release Only when all previous actions are signed off, publish the UMD/CMD release.
2.8 EGI Operations Post-release cleanup Post-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


Responsible Action Notes
3.1 Product team 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
    • 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 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.