Difference between revisions of "EGI Cloud Middleware Distribution process"
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. | ||
== Verification == | == Verification == | ||
== Staged-Rollout == | == Staged-Rollout == |
Revision as of 11: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:
|
at TP convenience |
2 | Injection | UMD Team SR Manager | inject the product release in the EGI SW provisioning infrastructure:
|
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:
|
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:
| |
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:
|
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.