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
Line 1: Line 1:
{{Template:Op menubar}} {{Template:Doc_menubar}} {{TOC_right}}
{{Ops_procedures
|Doc_title = Middleware release procedure
|Doc_link = https://wiki.egi.eu/wiki/PROC25
|Version = 0.1
|Policy_acronym = OMB
|Policy_name = Operations Management Board
|Contact_group =  operations at egi.eu
|Doc_status = DRAFT
|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.
}}
= 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 [[Glossary|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 https://wiki.egi.eu/wiki/Instructions_for_Production_Tools_teams#Release_and_deployment_management]
= Steps =  
= Steps =  


Line 56: Line 22:
* 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"
|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
|3
|
|UMD team, quality assurance
|
|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. 
* Perform the verification in the testbed
* 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.
* 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
|-
|-
|
|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 movedo to the "Delayed" status with an explanation for the delay
|-
|-
|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 "UMD Store"
** 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 =
|
# The whole process should not last longer than 2 months without providing any information to the product team about delays through the RT ticket.
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-

Revision as of 17:39, 21 July 2016

Steps


Responsible Action Notes
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
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 UMD 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.
3 UMD team, quality assurance 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.
  • Perform the verification in the testbed
  • 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.
  • 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
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 movedo to the "Delayed" status with an explanation for the delay
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 "UMD Store"
    • 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.