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
 
(35 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  
##  Release notes, or the link to them. The release notes should link to the advisory written by the Software Vulnerability Group (SVG), in the case of a software vulnerability.
##  Changelog, or the link to it. This can be already provided either inside the package or be part of the release notes.
##  Certification report(s) (from the agreed quality assurance documentation and tests) or a link.
##  Link to documentation: users manual, system administration manual, etc. The documentation should be updated if applicable, for example if the release introduces new functionality.
##  Links to all bugs, issues, features in this new release. This can be already provided either inside the package or be part of the release notes.
##  The URL of the SW provider repository. Either this is agreed and documented apriori, or should be given in the GGUS ticket so that the EGI repository managers can download the packages.
# 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 15: Line 12:
## The Repo parses the attached xml  
## 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  
## 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.
### '''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 information 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.3 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)  
## Verifies the new version. This includes the verification of all information provided according to point 1.
## '''EGI TUG -- The ticket is assigned a verifier'''
###  If the verification is successful the packages are moved into the "Staged Rollout" repository.
## '''EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .'''
### If there are problems or issues, then the component should be rejected in which case the RT ticket "Outcome" is set to "Rejected" and the "Status to "done. At this point a notification to the GGUS ticket is sent with the resulting value of "Rejected", whereby the Software Provider is notified.
## '''EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification'''
##  Inserts the URL of the repository or the URL of all the packages in the RT ticket. This will be used later by the early adopters to preform the staged-rollout.
## '''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'''
## Sets the status of the RT ticket to "Verified". At this point the ticket will be assigned to "staged-rollout" group which is thus notified that new packages are ready for the staged-rollout.
## '''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'''
'''MDavid: when the tech unit changes the RT ticket "Status" Verified->Rolling-out it will trigger in the repo the passage of the packages
from Unverified -> Staged-rollout repository. The Tech unit should "Assigned" the ticket to "Staged-rollout", that's how the staged rollout
managers are notified and take over the ticket.'''
# 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
# The Repo Processes the ticket  
# The Repo Processes the ticket  
## Move the SW to stage-rollout  
## 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.
## 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 Staged-Rollout managers
#    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, the Staged-Rollout managers change the RepoAction field to “MoveToProduction”  
#    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
#    Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
#    The Repo Processes the ticket  
#    The Repo Processes the ticket  
##    Move the SW to production  
##    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.
##    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 ….
…. and the life goes on ….
Line 50: 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 60: 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 67: 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 74: 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)