Difference between revisions of "PROC25"
Jump to navigation
Jump to search
Line 1: | Line 1: | ||
= 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
|
|
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. |
3 | UMD 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.
|
4 | Staged Rollout manager | Begin staged rollout
|
This action must be completed in one month
|
5 | Staged rollout manager | Complete staged rollout
|
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.