Difference between revisions of "PROC25"
Line 42: | Line 42: | ||
! Notes | ! Notes | ||
|- valign="top" | |- valign="top" | ||
|1 | |1.1 | ||
|Product team | |Product team | ||
|submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information | |submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information | ||
Line 50: | Line 50: | ||
| | | | ||
|- | |- | ||
|2 | |1.2 | ||
|Stage rollout manager | |Stage rollout manager | ||
|product release is injected in the EGI SW provisioning infrastructure | |product release is injected in the EGI SW provisioning infrastructure | ||
Line 59: | Line 59: | ||
|This action must be completed within ''5 working days'' after step 1. | |This action must be completed within ''5 working days'' after step 1. | ||
|- | |- | ||
|3 | |1.3 | ||
|UMD team, quality assurance | |UMD team, quality assurance | ||
|Begin of verification | |Begin of verification | ||
Line 72: | Line 72: | ||
* 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 | * 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 | ||
|- | |- | ||
|4 | |1.4 | ||
|Staged Rollout manager | |Staged Rollout manager | ||
|Begin staged rollout | |Begin staged rollout | ||
Line 81: | Line 81: | ||
* Tickets more than one month in the "Staged rollout" status must be movedo to the "Delayed" status with an explanation for the delay | * Tickets more than one month in the "Staged rollout" status must be movedo to the "Delayed" status with an explanation for the delay | ||
|- | |- | ||
|5 | |1.5 | ||
|Staged rollout manager | |Staged rollout manager | ||
|Complete staged rollout | |Complete staged rollout | ||
Line 102: | Line 102: | ||
! Notes | ! Notes | ||
|- | |- | ||
|1 | |2.1 | ||
|EGI Operations | |EGI Operations | ||
|Freeze UMD release contents | |Freeze UMD release contents | ||
|Using the UMD Composer add all products that are queued in the UMDStore to a new UMD release bundle. | |Using the UMD Composer add all products that are queued in the UMDStore to a new UMD release bundle. | ||
|- | |- | ||
|2 | |2.2 | ||
|Staged rollout manager | |Staged rollout manager | ||
|Prepare wiki page for the release with known issues and installation notes | |Prepare wiki page for the release with known issues and installation notes | ||
| | | | ||
|- | |- | ||
|3 | |2.3 | ||
|Create wiki entry | |Create wiki entry | ||
|Staged rollout manager | |Staged rollout manager | ||
Line 118: | Line 118: | ||
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. | 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. | ||
|- | |- | ||
|4 | |2.4 | ||
|Check for security vulnerabilities affecting existing products | |Check for security vulnerabilities affecting existing products | ||
|Staged rollout manager | |Staged rollout manager | ||
Line 129: | Line 129: | ||
| | | | ||
|- | |- | ||
|5 | |2.5 | ||
|EGI Operations | |EGI Operations | ||
|Compile release documentation in the release web site | |Compile release documentation in the release web site | ||
Line 141: | Line 141: | ||
*Change Log | *Change Log | ||
|- | |- | ||
|6 | |2.6 | ||
|Produce release candidate | |Produce release candidate | ||
|EGI Operations | |EGI Operations | ||
|From the list of included products in (1) generate a Release Candidate. Notify quality assurance UMD team. | |From the list of included products in (1) generate a Release Candidate. Notify quality assurance UMD team. | ||
|- | |- | ||
|7 | |2.7 | ||
|Test release candidate | |Test release candidate | ||
|UMD quality assurance team | |UMD quality assurance team | ||
Line 153: | Line 153: | ||
* 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 | * 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 | ||
|- | |- | ||
|8 | |2.8 | ||
|Publish UMD release | |Publish UMD release | ||
|EGI Operations | |EGI Operations | ||
|Only when all previous actions are signed off, publish the UMD release. | |Only when all previous actions are signed off, publish the UMD release. | ||
|- | |- | ||
|9 | |2.9 | ||
|Post-release cleanup | |Post-release cleanup | ||
|EGI Operations | |EGI Operations | ||
Line 165: | Line 165: | ||
* 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 | * 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 |
Revision as of 17:50, 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