Difference between revisions of "PROC25"
Line 171: | Line 171: | ||
* Major incident | * Major incident | ||
* Critical security vulnerability | * Critical security vulnerability | ||
== Steps for emergency release == |
Revision as of 17:54, 25 July 2016
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 produc 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 prerequesites are:
- The product team releasing the software has already provided the information to fill the product ID Card.
- Development team should follow https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management
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
|
|
1.2 | Stage rollout manager | product release is injected in the EGI SW provisioning infrastructure
|
This action must be completed within 5 working days after step 1. |
1.3 | UMD team, quality assurance | 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 | Staged Rollout manager | Begin staged rollout
|
This action must be completed in one month
|
1.5 | Staged rollout manager | Complete staged rollout
|
Notes
- 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 update
Responsible | Action | Notes | ||
---|---|---|---|---|
2.1 | EGI Operations | Freeze UMD release contents | Using the UMD Composer add all products that are queued in the UMDStore to a new UMD release bundle. | |
2.2 | Staged rollout manager | Prepare wiki page for the release with known issues and installation notes | ||
2.3 | Create wiki entry | Staged rollout manager | Create a Wiki entry for the release at UMD-x:UMD-x.y.z using the major (x), minor (y) and revision (z) numbers of the UMD release.
Create sections for each product that is included in the documented UMD 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.4 | Check for security vulnerabilities affecting existing products | Staged rollout manager | Use the Vulnerabilities Dashboard, and contact Linda Cornwall about any advisories on any pending security vulnerabilities that require cross-linking
|
|
2.5 | EGI Operations | Compile release documentation in the release web site | UMD release metadata will be published in the UMD Repository and must cover the following sections:
| |
2.6 | Produce release candidate | EGI Operations | From the list of included products in (1) generate a Release Candidate. Notify quality assurance UMD team. | |
2.7 | Test release candidate | UMD quality assurance team | The release candidate is automatically tested for installability and dependencies problems.
| |
2.8 | Publish UMD release | EGI Operations | Only when all previous actions are signed off, publish the UMD release. | |
2.9 | Post-release cleanup | EGI Operations | Post-release actions perform some housekeeping in the UMD 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