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 "EGI Cloud Middleware Distribution process"

From EGIWiki
Jump to navigation Jump to search
Line 21: Line 21:
| 2
| 2
| Injection
| Injection
| UMD SR Manager
| UMD Team SR Manager
| inject the product release in the EGI SW provisioning infrastructure:  
| inject the product release in the EGI SW provisioning infrastructure:  
* One or more RT tickets are created to track the progress of the inclusion of the new product release; the status of the product release will then be tracked in RT, the status of the RT ticket just is initially '''Unverified'''
* One or more RT tickets are created to track the progress of the inclusion of the new product release; the status of the product release will then be tracked in RT, the status of the RT ticket just is initially '''Unverified'''
Line 29: Line 29:
| 3
| 3
| Quality Verification starts
| Quality Verification starts
| QC Verifier
| UMD Team QC Verifier
| the QC verifier starts the verification process
| the QC verifier starts the verification process, switching the status of the RT ticket from "Unverified" to "Verification"
| in '''one month''' after the creation of the RT ticket; after a month with the verification not yet started:  
| the QC verification must start in '''one month''' after the creation of the RT ticket; after a month with the verification not yet started:  
* the RT ticket will be updated with an explanation for the delay
* the RT ticket will be updated with an explanation for the delay
* the status will be changed to "Delayed" [*]
* the status will be changed to "Delayed" [*]
Line 37: Line 37:
|-
|-
| 4
| 4
|  
| Quality Verification execution
| the UMD team is verifying the product in the testbed; after the verification process is completed, the RT ticket status is switched from "Verification" to "Staged Rollout"
| an RT ticket cannot stay longer than '''one week''' in verification; after one week with the verification not yet completed:
* the RT ticket will be updated with an explanation for the delay
* the status will be changed to "Delayed" [*]
* the Technology Provider will be informed (using the contacts in the [https://wiki.egi.eu/wiki/EGI_Cloud_Middleware_Distribution_products product ID card])
|-
| 5
| Staged Rollout
| UMD Team Staged Rollout manager
| The product is announced to the early adopters testing the product in staged rollout.
| RT tickets cannot stay longer than '''one month''' in the "Staged Rollout" status; after a month with the staged rollout not yet completed:
* the RT ticket will be updated with an explanation for the delay
* the status will be changed to "Delayed" [*]
* the Technology Provider will be informed (using the contacts in the [https://wiki.egi.eu/wiki/EGI_Cloud_Middleware_Distribution_products product ID card])
|-
| 6
| Inclusion in the next release
| Release manager
| include the product in the next release
|}
|}


[*] Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.   
[*] Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.   
# The RT ticket is in "Verification" status
#* This means that the UMD team is verifying the product in the testbed.
#* 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.
# Product is in "Staged Rollout" Status
#* The product is announced to the early adopters testing in staged rollout the product.
#* #* RT cannot stay longer than '''one month''' in the "Staged Rollout" status
#* After one month, if it has not been tested in staged rollout it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
# After the staged rollout product is ready to be included in the next UMD release


== Verification ==
== Verification ==
== Staged-Rollout ==
== Staged-Rollout ==

Revision as of 10:44, 4 October 2016

CMD menu: Overview Products Process Release schedule


Description of the process

Step Action Action on Description Timeline
1 Submission Technology Provider submit a GGUS ticket, assigned to Support Unit "EGI Software provisioning support", providing them 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
at TP convenience
2 Injection UMD Team SR Manager inject the product release in the EGI SW provisioning infrastructure:
  • One or more RT tickets are created to track the progress of the inclusion of the new product release; the status of the product release will then be tracked in RT, the status of the RT ticket just is initially Unverified
  • The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and closes as 'solved' the GGUS ticket
5 working days
3 Quality Verification starts UMD Team QC Verifier the QC verifier starts the verification process, switching the status of the RT ticket from "Unverified" to "Verification" the QC verification must start in one month after the creation of the RT ticket; after a month with the verification not yet started:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
4 Quality Verification execution the UMD team is verifying the product in the testbed; after the verification process is completed, the RT ticket status is switched from "Verification" to "Staged Rollout" an RT ticket cannot stay longer than one week in verification; after one week with the verification not yet completed:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
5 Staged Rollout UMD Team Staged Rollout manager The product is announced to the early adopters testing the product in staged rollout. RT tickets cannot stay longer than one month in the "Staged Rollout" status; after a month with the staged rollout not yet completed:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
6 Inclusion in the next release Release manager include the product in the next release

[*] Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.

Verification

Staged-Rollout