Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "PROC25"

From EGIWiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 10: Line 10:
|Doc_status = DRAFT
|Doc_status = DRAFT
|Approval_date =  
|Approval_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.  
|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 = Vincenzo Spinoso
}}
}}


Line 28: Line 29:
= Requirements  =
= Requirements  =


The prerequesites are:  
The prerequisites are:  


*The product team releasing the software has already provided the information to fill the product ID Card.
*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 [https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management]
** [[UMD_products_ID_cards | UMD ID card]]
** [[EGI_Cloud_Middleware_Distribution_products#Product_ID_card_description | CMD ID card]]
*Development team should follow [[Instructions_for_Production_Tools_teams#Release_and_deployment_management | Instructions for Production Tools teams: Release and deployment management]]


= Steps for the validation of individual product releases =
= Steps for the validation of individual product releases =
Line 44: Line 47:
|1.1
|1.1
|Product team
|Product team
|submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information
|[https://ggus.eu/?mode=ticket_submit Submits a GGUS ticket] for the "'''EGI Software provisioning support'''" support unit with the following information
* Product release and version number
* Product release and version number
* Link to the release notes
* Link to the release notes
* Full list of packages that compose the release, and that need to be released in UMD
* Full list of packages that compose the release and that need to be released in UMD/CMD
|
|
|-
|-
|1.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.
* One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release
* 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
* 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 is then used to track the progress of the software in the release process.
* The RT ticket status is now "unverified"
* The RT ticket status is now "unverified".
|This action must be completed within ''5 working days'' after step 1.
|This action must be completed within ''5 working days'' after step 1.
|-
|-
|1.3
|1.3
|UMD team, quality assurance
| Software provisioning team, quality assurance
|Begin of verification
|Begin of verification
*Move the RT ticket created in step 2 in the ""Verification" status. This means that the UMD team is verifying the product in the testbed.   
*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
* Perform the verification in the testbed.
* Attach verification report to the RT ticket
* Attach verification report to the RT ticket.
*An RT ticket cannot stay longer than one week in verification   
*After one week, if it has not been verified it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.  
|This action must start within ''one month'' after step 2 is completed.
|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
* 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''.
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
* 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
|1.4
Line 77: Line 78:
* Move the ticket from "Verification" or "Delayed" to the "Staged rollout" status
* 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 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
* The reports provided by the early adopters are attached to the RT ticket.
|This action must be completed in ''one month''  
|This action must be completed in ''one month''.
* 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 moved to the "Delayed" status with an explanation for the delay.
|-
|-
|1.5
|1.5
|Staged rollout manager
|Staged rollout manager
|Complete staged rollout
|Complete staged rollout.
* Evaluate the reports and take a decision about the release
* Evaluate the reports and take a decision about the release.
** If the product release qualifies for production the RT is moved to "UMD Store"
** 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.
** If the product release does not qualify for production the RT ticket is moved to "Rejected" and an explanation is provided to the developers.
|
|
Line 93: Line 94:
# The whole process should not last longer than 2 months without providing any information to the product team about delays through the RT ticket.
# 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 =
= Step for the release of a UMD/CMD update =


{| width="906" height="305" class="wikitable"
{| width="906" height="305" class="wikitable"
Line 104: Line 105:
|2.1
|2.1
|EGI Operations
|EGI Operations
|Freeze UMD release contents
|Freeze UMD/CMD 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/CMD release bundle.
|-
|-
|2.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
|
|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
|2.3
|Create wiki entry
|Staged rollout manager
|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
|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
|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.
*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.
*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.
*UMD release manager cross checks this dashboard with any planned UMD releases.
*Release manager cross checks this dashboard with any planned releases.
*The resulting list is circulated to UMD release documentation team (TSA2.3 and TSA1.3), and the RAT manager
*The resulting list is circulated to release documentation team (TSA2.3 and TSA1.3), and the RAT manager
*UMD releases CSIRT Advisories are published cross-referencing each other  
*Releases CSIRT Advisories are published cross-referencing each other  
|
|-
|-
|2.5
|2.4
|EGI Operations
|EGI Operations
|Compile release documentation in the release web site
|Compile release documentation in the release web site
|UMD release metadata will be published in the UMD Repository and must cover the following sections:
|UMD/CMD release metadata will be published in the UMD/CMD Repository and must cover the following sections:
*Description
*Description
*Contact Info
*Contact Info
Line 140: Line 138:
*Known Issues
*Known Issues
*Change Log  
*Change Log  
* RT tickets containing requirements associated to this release if available (''Added on 15 Nov 2017'')
|-
|-
|2.6
|2.5
|EGI Operations
|Produce release candidate
|Produce release candidate
|EGI Operations
|From the list of included products in (1) generate a Release Candidate. Notify quality UMD assurance team.
|From the list of included products in (1) generate a Release Candidate. Notify quality assurance UMD team.
|-
|-
|2.7
|2.6
|UMD quality assurance team
|Test release candidate
|Test release candidate
|UMD quality assurance team
|The release candidate is automatically tested for installability and dependencies problems.
|The release candidate is automatically tested for installability and dependencies problems.
* If the test goes well the procedure goes to next step
* 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
* 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
|2.8
|Publish UMD release
|EGI Operations
|EGI Operations
|Only when all previous actions are signed off, publish the UMD release.
|-
|2.9
|Post-release cleanup  
|Post-release cleanup  
|EGI Operations
|Post-release actions perform some housekeeping in the UMD/CMD release management area, including:
|Post-release actions perform some housekeeping in the UMD release management area, including:
* Add the UMD/CMD release announcement to UMD/CMD release schedule overview
* Add the UMD release announcement to UMD 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
* 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
|}
|}
Line 173: Line 172:


== Steps for emergency release ==
== Steps for emergency release ==
{| width="906" height="305" class="wikitable"
|-
! <br>
! Responsible
! Action
! Notes
|-
|3.1
|Product team
|[https://ggus.eu/?mode=ticket_submit 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
|<br>
|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
|<br>
|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.
|}

Latest revision as of 15:38, 7 January 2019

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 Vincenzo Spinoso


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.