Difference between revisions of "EGI-InSPIRE:NSRW New Software Release Workflow"
Jump to navigation
Jump to search
Line 1: | Line 1: | ||
== Ticket LifeCycle == | == Ticket LifeCycle == | ||
# The SW Provider | |||
# The ticket is | # The SW Provider creates a Ticket in GGUS accompanied with all the necessary info | ||
# RT Notifies the Repo there is a | # The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“ | ||
# The Repo Processes the ticket | # Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed | ||
## | # The Repo Processes the ticket | ||
## Downloads the software bundle and puts it on the “Unverified” Repository | |||
## The Repo parses the attached xml | ## The Repo parses the attached xml | ||
## The Repo updates RT | ## Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions | ||
## The | ### '''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. | ||
# RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG) | ### '''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 | ||
# EGI TUG -- please fill in the | # In both 4.c cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG) | ||
# | ## '''EGI TUG -- please fill in the intermediate steps here concerning the 4.3.1 step.''' | ||
## | ## '''EGI TUG -- please fill in the intermediate steps here concerning the 4.3.2 step.''' | ||
## | # 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 | |||
## Move the SW to stage-rollout | |||
## 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 EA and/or '''MarioD''' or whoever is responsible to handle the stage-rollout process ('''MarioD?? any suggestion on this?''') | |||
# If everything it is OK, MarioD 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 | |||
## Move the SW to production | |||
## 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 …. | |||
... | ... |
Revision as of 16:22, 22 September 2010
Ticket LifeCycle
- The SW Provider creates a Ticket in GGUS accompanied with all the necessary info
- 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
- Downloads the software bundle and puts it on the “Unverified” Repository
- The Repo parses the attached xml
- Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
- 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.
- 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
- In both 4.c cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)
- EGI TUG -- please fill in the intermediate steps here concerning the 4.3.1 step.
- EGI TUG -- please fill in the intermediate steps here concerning the 4.3.2 step.
- 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
- Move the SW to stage-rollout
- 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 EA and/or MarioD or whoever is responsible to handle the stage-rollout process (MarioD?? any suggestion on this?)
- If everything it is OK, MarioD 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
- Move the SW to production
- 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