EGI-InSPIRE:NSRW New Software Release Workflow

Ticket LifeCycle

The SW Provider creates a Ticket in GGUS accompanied with all the necessary info:
1. Release notes, or the link to them. The release notes should link to the advisory written by the Software Vulnerability Group (SVG), in the case of a software vulnerability.
2. Changelog, or the link to it. This can be already provided either inside the package or be part of the release notes.
3. Certification report(s) (from the agreed quality assurance documentation and tests) or a link.
4. Link to documentation: users manual, system administration manual, etc. The documentation should be updated if applicable, for example if the release introduces new functionality.
5. Links to all bugs, issues, features in this new release. This can be already provided either inside the package or be part of the release notes.
6. The URL of the SW provider repository. Either this is agreed and documented apriori, or should be given in the GGUS ticket so that the EGI repository managers can download the packages.
The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“
Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
The Repo Processes the ticket
1. Downloads the software bundle and puts it on the “Unverified” Repository
2. The Repo parses the attached xml
3. Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
  1. Upon success: The Repo updates the RT setting the RepoStatus of the ticket to “Unverified” + the URI where the new software can be found, etc.
  2. In case of a failure: The Repo updates the RT, setting the RepoStatus of the ticket to “Failed”, plus it updates the ticket with a comment that contains the information related to the failure
In both 4.3 cases, the RT Notifies the EGI Technology Unit Group (i.e the Ticket is Assigned to the EGI TUG):
1. Verifies the new version. This includes the verification of all information provided according to point 1.
  1. If the verification is successful the packages are moved into the "Staged Rollout" repository.
  2. If there are problems or issues, then the component should be rejected in which case the RT ticket "Outcome" is set to "Rejected" and the "Status to "done. At this point a notification to the GGUS ticket is sent with the resulting value of "Rejected", whereby the Software Provider is notified.
2. Inserts the URL of the repository or the URL of all the packages in the RT ticket. This will be used later by the early adopters to preform the staged-rollout.
3. Sets the status of the RT ticket to "Verified". At this point the ticket will be assigned to "staged-rollout" group which is thus notified that new packages are ready for the staged-rollout.

MDavid: when the tech unit changes the RT ticket "Status" Verified->Rolling-out it will trigger in the repo the passage of the packages from Unverified -> Staged-rollout repository. The Tech unit should "Assigned" the ticket to "Staged-rollout", that's how the staged rollout managers are notified and take over the ticket.

If the TUG team decide that the release it is ready to move to stage-rollout phase, the RepoAction field of the ticket it is marked as MoveToStageRollOut
Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
The Repo Processes the ticket
1. Move the SW to stage-rollout
2. The Repo updates the RT setting the RepoStatus of the ticket to “Stage-Rollout” + the URI where the new software can be found, etc.
RT Notifies the Staged-Rollout managers
If everything it is OK, the Staged-Rollout managers change the RepoAction field to “MoveToProduction”
Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
The Repo Processes the ticket
1. Move the SW to production
2. The Repo updates the RT setting the RepoStatus of the ticket to “Production” + the URI where the new software can be found, etc.

…. and the life goes on ….

...