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.

EGI-InSPIRE:NSRW New Software Release Workflow

From EGIWiki
Jump to navigation Jump to search

Ticket LifeCycle

  1. 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 upload the packages.
  2. The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“
  3. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
  4. 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
  5. In both 4.3 cases, the RT Notifies the EGI Technology Unit Group (i.e the Ticket is Assigned to the EGI TUG)
    1. EGI TUG -- please fill in the intermediate steps here concerning the 4.3.1 step.
    2. EGI TUG -- please fill in the intermediate steps here concerning the 4.3.2 step.
  6. 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
  7. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
  8. 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.
  9. RT Notifies the EA and/or MarioD or whoever is responsible to handle the stage-rollout process (MarioD?? any suggestion on this?)
  10. If everything it is OK, MarioD change the RepoAction field to “MoveToProduction”
  11. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
  12. 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 ….

...

Required Fields

RepoAction : Actions to Be Performed by the Repo, Values MoveToUnverified,MoveToStageRollOut,MoveToProduction,Reject,Depreceate

RepoStatus : Response to RepoActions, Values Uverified,StateRollOut,Production,Depreceated,Failed

Work Flow

MetaData

NRMS New Release MetaDATA schema

Ticket Status Values

Questions/Issues

Insert any question / issue you may have here to keep track of them

Related Info

EGI-SW-Release-Workflow.png

Feedback from M. David

MS501

MS504

UMD RoadMap

MS504