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.

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

From EGIWiki
Jump to navigation Jump to search
 
(44 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 neccesary info  
 
# The ticket is Transfered from GGUS to RT, Status of the Ticket is New
# The SW Provider creates a Ticket in GGUS accompanied with all the necessary info  
# RT Notifies the Repo there is a new ticket to be processed, Status of the Ticket remains new  (i.e the Ticket is Assigned to  the REPO)
# 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 Downloads the software bundle and puts it on the Unverified Repository  
# 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 with the info extacted from the xml + the Uri where the new software can be found  
## Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
##  The Status of the ticket is set to Unverified
### '''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 intermedate steps here
# In both 4.3 cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)  
# Depending on the outcome
## '''EGI TUG -- The ticket is assigned a verifier'''
## if Success the Ticket is Marked MoveToStageRollOut, Go To Step X
## '''EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .'''
## if failure the Ticket is Marked Rejected, Go To Step Y
## '''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 ….


...
...
[[File:EGI-SW-Release-Workflow.png‎ ]]


== Required Fields ==
== Required Fields ==
Line 29: Line 45:




== MetaDATA ==
== 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 ==


[[NRMS New Release MetaDATA schema]]
[[NRMS New Release MetaDATA schema]]


== Ticket Status Values ==
== 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 ==
== Related Info ==
[[File:EGI-SW-Release-Workflow.png‎ ]]


[[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 45: 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 MS504]
[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 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)