Difference between revisions of "EGI-InSPIRE:NSRW New Software Release Workflow"
Jump to navigation
Jump to search
(38 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
{{EGI-Inspire_menubar}} | |||
{{TOC_right}} | |||
== Ticket LifeCycle == | == Ticket LifeCycle == | ||
# The SW Provider creates a Ticket in GGUS accompanied with all the necessary info | # 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“ | # 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 | # Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed | ||
Line 16: | Line 14: | ||
### '''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. | ### '''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 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. | # In both 4.3 cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG) | ||
## '''EGI TUG -- | ## '''EGI TUG -- The ticket is assigned a verifier''' | ||
## '''EGI TUG -- | ## '''EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .''' | ||
## '''EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification''' | |||
## '''EGI TUG -- If the verification is not OK, and minor issues are found, the SP is notified and has 1-2 days (depending on the type of release) to solve or clarify the issues. The ticket is moved to Verified-issues''' | |||
## '''EGI TUG -- If the verification is not OK, and has major issues or the grace-period has passed without correcting the issues, the ticket is moved to Rejected and the SP get a notification''' | |||
# 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 | # 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 | # Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed | ||
Line 43: | Line 44: | ||
== Work Flow == | == Work Flow == | ||
== Proposed Structure for the Repository == | |||
[[http://repository.egi.eu/sw/ Protoytpe Repo]] | |||
'''stagerollout''' | |||
<pre> | |||
/sw/stagerollout/CAs/egi/ | |||
/sw/stagerollout/CAs/lcg/ | |||
/sw/stagerollout/umd/1.0/….. | |||
/sw/stagerollout/globus/x/x.y/….. | |||
/sw/stagerollout/jra1/nagios/ | |||
/sw/stagerollout/jra1-sw1 | |||
/sw/stagerollout/jra1-sw2 | |||
/sw/stagerollout/………. | |||
</pre> | |||
'''Production''' | |||
<pre> | |||
/sw/production/CAs/egi/ | |||
/sw/production/CAs/lcg/ | |||
/sw/production/umd/1.0/….. | |||
/sw/production/globus/x/x.y/….. | |||
/sw/production/jra1/nagios/ | |||
/sw/production/jra1/jra1-sw1/ | |||
/sw/production/jra1/jra1-sw2/ | |||
/sw/production/………. | |||
</pre> | |||
== MetaData == | == MetaData == | ||
Line 53: | Line 84: | ||
Insert any question / issue you may have here to keep track of them | Insert any question / issue you may have here to keep track of them | ||
* '''Define Scope of a Release (e.g. delta to a respective base Bundle or not ?)''' | |||
* '''Define / Finalize the Relese Metadata Schema.''' | |||
[[EGI REPO Team Issues]] | |||
== Related Info == | == Related Info == | ||
Line 60: | Line 96: | ||
[[Feedback from M. David]] | [[Feedback from M. David]] | ||
[[Feedback from M. Drescher]] | |||
[[NSRW_feedback_Milos_and_Ales]] | |||
Current Quality Criteria: [[EGI-InSPIRE:UMDQualityCriteria]] | |||
The current template for Quality Criteria verification can be found [https://documents.egi.eu/secure/ShowDocument?docid=208 here]. | |||
[https://documents.egi.eu/secure/ShowDocument?docid=46 MS501] | [https://documents.egi.eu/secure/ShowDocument?docid=46 MS501] | ||
[https://documents.egi.eu/secure/ShowDocument?docid=68 MS503] | |||
[https://documents.egi.eu/secure/ShowDocument?docid=89 MS504] | [https://documents.egi.eu/secure/ShowDocument?docid=89 MS504] | ||
Line 67: | Line 113: | ||
[https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap] | [https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap] | ||
[https://documents.egi.eu/secure/ShowDocument?docid=53 | [https://documents.egi.eu/secure/ShowDocument?docid=53 MS402] | ||
[[NGI_CZ:RT_GGUS_Integration]] | |||
[[NSRW_IMPLEMENTATION_RT]] | |||
[[Quality_Assurance:Main_Page]] | |||
[https://documents.egi.eu/secure/ShowDocument?docid=55 Metrics] | |||
[[Internal TPs Process for a new software release]] | |||
--[[User:Kkoum|Kkoum]] 07:17, 28 September 2010 (UTC) |
Latest revision as of 23:19, 24 December 2014
EGI Inspire Main page |
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.3 cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)
- EGI TUG -- The ticket is assigned a verifier
- EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .
- EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification
- EGI TUG -- If the verification is not OK, and minor issues are found, the SP is notified and has 1-2 days (depending on the type of release) to solve or clarify the issues. The ticket is moved to Verified-issues
- EGI TUG -- If the verification is not OK, and has major issues or the grace-period has passed without correcting the issues, the ticket is moved to Rejected and the SP get a notification
- 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
Proposed Structure for the Repository
stagerollout
/sw/stagerollout/CAs/egi/ /sw/stagerollout/CAs/lcg/ /sw/stagerollout/umd/1.0/….. /sw/stagerollout/globus/x/x.y/….. /sw/stagerollout/jra1/nagios/ /sw/stagerollout/jra1-sw1 /sw/stagerollout/jra1-sw2 /sw/stagerollout/……….
Production
/sw/production/CAs/egi/ /sw/production/CAs/lcg/ /sw/production/umd/1.0/….. /sw/production/globus/x/x.y/….. /sw/production/jra1/nagios/ /sw/production/jra1/jra1-sw1/ /sw/production/jra1/jra1-sw2/ /sw/production/……….
MetaData
NRMS New Release MetaDATA schema
Ticket Status Values
Questions/Issues
Insert any question / issue you may have here to keep track of them
- Define Scope of a Release (e.g. delta to a respective base Bundle or not ?)
- Define / Finalize the Relese Metadata Schema.
Related Info
Current Quality Criteria: EGI-InSPIRE:UMDQualityCriteria
The current template for Quality Criteria verification can be found here.
Internal TPs Process for a new software release
--Kkoum 07:17, 28 September 2010 (UTC)