Difference between revisions of "PROC25"
(→Step for the release of a UMD/CMD update)
(→Step for the release of a UMD/CMD update)
|Line 137:||Line 137:|
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|
|Policy Group Acronym||OMB|
|Policy Group Name||Operations Management Board|
|Contact Group||operations at egi.eu|
|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|
The procedure describes the process to add a new product, or a new release of an existing product to the UMD/CMD repositories.
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.
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 team should follow Instructions for Production Tools teams: Release and deployment management
Steps for the validation of individual product releases
|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||Software provisioning 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.
- 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
|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:
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
|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:
|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.
|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:
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
|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.|