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
Revision as of 11:14, 23 September 2010 by Kkoum (talk | contribs)
Jump to navigation Jump to search

Ticket LifeCycle

  1. The SW Provider creates a Ticket in GGUS accompanied with all the necessary info
  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 info related to the failure
  5. In both 4.c 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

MDavid: the (in)famous below graph needs to be updated

Related Info

EGI-SW-Release-Workflow.png

Feedback from M. David

MS501

MS504

UMD RoadMap

MS402

NGI_CZ:RT_GGUS_Integration