Difference between revisions of "EGI-InSPIRE:NSRW New Software Release Workflow"

From EGIWiki
Jump to: navigation, search
(Related Info)
 
(26 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 +
{{EGI-Inspire_menubar}}
 +
{{TOC_right}}
 +
 
== Ticket LifeCycle ==
 
== Ticket LifeCycle ==
  
Line 11: 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.c cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)  
+
# 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 -- please fill in the intermediate steps here concerning the 4.3.1 step.'''
+
## '''EGI TUG -- The ticket is assigned a verifier'''
## '''EGI TUG -- please fill in the intermediate steps here concerning the 4.3.2 step.'''
+
## '''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 38: 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 49: Line 85:
 
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
  
MDavid: the (in)famous below graph needs to be updated
+
* '''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 57: 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 116:
  
 
[[NGI_CZ:RT_GGUS_Integration]]
 
[[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 22:19, 24 December 2014

EGI Inspire Main page



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.3 cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)
    1. EGI TUG -- The ticket is assigned a verifier
    2. EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .
    3. EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification
    4. 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
    5. 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
  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

Proposed Structure for the Repository

[Protoytpe Repo]

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.

EGI REPO Team Issues

Related Info

EGI-SW-Release-Workflow.png

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 here.

MS501

MS503

MS504

UMD RoadMap

MS402

NGI_CZ:RT_GGUS_Integration

NSRW_IMPLEMENTATION_RT

Quality_Assurance:Main_Page

Metrics

Internal TPs Process for a new software release

--Kkoum 07:17, 28 September 2010 (UTC)