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 "Staged Rollout process"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{Template:Op menubar}}
{{Template:Op menubar}} {{TOC_right}}  
{{TOC_right}}
=New Software Release Workflow=
The full description of the New Software Release Workflow (NSRW) includes all stages from software release by a Technology Provider to release for deployment in the EGI production infrastructure.
* Workflow [https://wiki.egi.eu/wiki/NSRW_New_Software_Release_Workflow description] (this workflows now obsoletes what defined in [https://documents.egi.eu/document/53 MS402])
* Workflow [https://wiki.egi.eu/wiki/NSRW_IMPLEMENTATION_RT implementation in RT]


The remainder of this document describes the part of the workflow corresponding to the '''Staged Rollout''' phase.
= New Software Release Workflow =


= Staged Rollout Workflow=
The full description of the New Software Release Workflow (NSRW) includes all stages from software release by a Technology Provider to release for deployment in the EGI production infrastructure.  
The staged rollout start when the state of the RT ticket in the queue '''sw-rel'''
changes from '''InVerification''' to '''StageRollOut''', this means that the SW component as
passed the verification process.


It is assumed that the staged rollout repository is fixed for any given major release of any SW, this is publicly available in the repository and EGI wiki for Early Adopters. This state change triggers the following actions:
*Workflow [https://wiki.egi.eu/wiki/NSRW_New_Software_Release_Workflow description] (this workflows now obsoletes what defined in [https://documents.egi.eu/document/53 MS402])
*Workflow [https://wiki.egi.eu/wiki/NSRW_IMPLEMENTATION_RT implementation in RT]


# The SW packages are moved from the '''InVerification''' repository to the '''StageRollOut''' repository.
The remainder of this document describes the part of the workflow corresponding to the '''Staged Rollout''' phase.  
# The '''sw-rel''' ticket creates a new child ticket in the '''staged-rollout''' queue.
## The ownership of the sw-rel ticket is changed to the SSO group '''sw-rel-sr'''.
# <big>'''(Staged Rollout Manager)'''</big> The staged rollout managers '''staged-rollout''' SSO group is notified when the child ticket in queue '''staged-rollout''' is created.
## The '''staged-rollout''' ticket should contain the links to:
### Release notes, contains information about install/upgrade and configuration.
### Bugs or issues fixed.
### Documentation.
## The status of the ticket is '''new'''.
# <big>'''(Staged Rollout Manager)'''</big> The queue '''staged-rollout''' has a custom field (dropped down) where the staged rollout managers select the EA teams to assign the staged rollout test.
## <big>'''(Staged Rollout Manager)'''</big> The status of the ticket is changed to '''open'''.
## <big>'''(EA teams)'''</big> Each EA team has to acknowledge the reception of the notification within 1 working day. Either by replying to the mail sent by the RT or directly in the ticket with:
### <big>'''(EA teams)'''</big> '''<accept|reject>'''  '''<NGI>-<Site-name>'''
## <big>'''(Staged Rollout Manager)'''</big> The staged rollout manager will check the ticket and if there are no EAs accepting the staged rollout test, it will pool the '''early-adopters-XXX.mailman.egi.eu''' mailing lists, and other (s)he see’s fit to get other EA sites.
# <big>'''(EA teams)'''</big> The EA team has the option to put the service node into downtime in the GOCDB, special '''beta''' tag. This tag may be set only during the staged rollout phase, if/when the component is release into production, this tag (or downtime), should be removed from the gocdb.
# <big>'''(EA teams)'''</big> The EA teams do the staged rollout: install/upgrade, configure, and some tests as they see fit.
## <big>'''(EA teams)'''</big> If the EA finds problems or issues, either they are clarified within the ticket by the staged rollout managers and other EA teams, OR , a GGUS ticket should be opened.
## <big>'''(EA teams)'''</big> If a GGUS ticket is opened, this ticket should be assigned to the DMSU support unit, which will then route it to the technology providers as they see fit.
## <big>'''(EA teams)'''</big> A link to the GGUS ticket should be created in the staged rollout ticket.
# <big>'''(EA teams)'''</big> The service should ideally be exposed into production load/environment and users. This period may last between 5 to 7 days, but may be extended depending on the cases.
# <big>'''(EA teams)'''</big> Each EA team should fill the '''staged rollout''' templates after the last point, and attach it to the '''staged-rollout''' ticket:
## <big>'''(EA teams)'''</big> The report should contain as much information as possible, specially the correctness of the release notes, test that have been preformed, and possible metrics when the service is exposed to production (like number of jobs per day, or number of transfers, what VOs are configured for that service, etc.)
## <big>'''(EA teams)'''</big> The name of the file should be:
### '''ea-<NGI>-<Site-name>-<MW stack>-<component>-<version>'''.EXT (doc, docx, odt)
# <big>'''(Staged Rollout Manager)'''</big> The staged rollout managers:
## Collect all reports and may produce a summary report.
## Create a document in the EGI Doc server with a given ID, which will contain all reports for the staged rollout of that component, as well as the summary report.
## Insert a link to the Dec server ID of the reports.
## Write the outcome '''<ACCEPT|REJECT>''' in a custom field.
## Set the ticket status to '''resolved'''.
# <big>'''(Staged Rollout Manager)'''</big> When the staged rollout child ticket is set to '''resolved''' the parent ticket is notified, and it should get the outcome and the doc server id of the reports.


=Resources=
= Staged Rollout Workflow =
* The Staged Rollout process is supported by the RT ticketing system (see tickets in the '''staged-rollout''' queue).
* Report templates: each Early Adopter has to fill in a report (see the [https://documents.egi.eu/public/ShowDocument?docid=254 template] on DocumentDB.


=Naming conventions=
The staged rollout start when the '''"RolloutProgress'''" custom field of RT ticket in the queue '''sw-rel''' changes from "'''InVerification"''' to "'''StageRollOut"''', this means that the SW component as passed the verification process, i.e. was "'''ACCEPTED'''" in the verification phase.This triggers the creation of a child ticket in the "'''staged-rollout'''"&nbsp;queue, where all the Staged Rollout process occurs.<br>
* The EA team names are SSO groups containing the members of each team:
** '''ea-< NGI >-< Site-name >'''


* The custom fields needed in the '''staged-rollout''' queue are:
It is assumed that the staged rollout repository is fixed for any given major release of any SW, this is publicly available in the repository and EGI wiki for Early Adopters. This state change triggers the following actions:  
** Drops down box containing all EA teams, on the EGI SSO: possibility to select several teams, the button '''Save Changes''' notifies those teams and they will be added to the '''AdminCC''' field.
** Outcome of the staged rollout, drop down box with: '''< ACCEPT | REJECT >'''.


* The title of the ticket is of the form:
#The SW packages are moved from the '''InVerification''' repository to the '''StageRollOut''' repository.
** '''“Staged Rollout < SW stack-MajorVersion > < COMPONENT > < VERSION > < OS > < ARCH >”'''
#The '''sw-rel''' ticket creates a new child ticket in the '''staged-rollout''' queue.
** Examples:
##The ownership of the sw-rel ticket is changed to the SSO group '''sw-rel-sr'''.
*** '''Staged Rollout CA 1.38'''
#<big>'''(Staged Rollout Manager)'''</big> The staged rollout managers '''staged-rollout''' SSO group is notified when the child ticket in queue '''staged-rollout''' is created.
*** '''Staged Rollout EMI-1.0 SE-DPM_mysql 1.8.0-1 SL5 x86_64'''
##The '''staged-rollout''' ticket should contain the links to:
###Release notes, contains information about install/upgrade and configuration.
###Bugs or issues fixed.
###Documentation.
##The status of the ticket is '''new'''.
#<big>'''(Staged Rollout Manager)'''</big> The queue '''staged-rollout''' has a custom field (dropped down) where the staged rollout managers select the EA teams to assign the staged rollout test.
##<big>'''(Staged Rollout Manager)'''</big> The status of the ticket is changed to '''open'''.
##<big>'''(EA teams)'''</big> Each EA team has to acknowledge the reception of the notification within 1 working day. Either by replying to the mail sent by the RT or directly in the ticket with:  
###<big>'''(EA teams)'''</big> '''&lt;accept|reject&gt;''' '''&lt;NGI&gt;-&lt;Site-name&gt;'''
##<big>'''(Staged Rollout Manager)'''</big> The staged rollout manager will check the ticket and if there are no EAs accepting the staged rollout test, it will pool the '''early-adopters-XXX.mailman.egi.eu''' mailing lists, and other (s)he see’s fit to get other EA sites.
#<big>'''(EA teams)'''</big> The EA team has the option to put the service node into downtime in the GOCDB, special '''beta''' tag. This tag may be set only during the staged rollout phase, if/when the component is release into production, this tag (or downtime), should be removed from the gocdb.
#<big>'''(EA teams)'''</big> The EA teams do the staged rollout: install/upgrade, configure, and some tests as they see fit.
##<big>'''(EA teams)'''</big> If the EA finds problems or issues, either they are clarified within the ticket by the staged rollout managers and other EA teams, OR , a GGUS ticket should be opened.
##<big>'''(EA teams)'''</big> If a GGUS ticket is opened, this ticket should be assigned to the DMSU support unit, which will then route it to the technology providers as they see fit.
##<big>'''(EA teams)'''</big> A link to the GGUS ticket should be created in the staged rollout ticket.
#<big>'''(EA teams)'''</big> The service should ideally be exposed into production load/environment and users. This period may last between 5 to 7 days, but may be extended depending on the cases.
#<big>'''(EA teams)'''</big> Each EA team should fill the '''staged rollout''' templates after the last point, and attach it to the '''staged-rollout''' ticket:  
##<big>'''(EA teams)'''</big> The report should contain as much information as possible, specially the correctness of the release notes, test that have been preformed, and possible metrics when the service is exposed to production (like number of jobs per day, or number of transfers, what VOs are configured for that service, etc.)
##<big>'''(EA teams)'''</big> The name of the file should be:
###'''ea-&lt;NGI&gt;-&lt;Site-name&gt;-&lt;MW stack&gt;-&lt;component&gt;-&lt;version&gt;'''.EXT (doc, docx, odt)
#<big>'''(Staged Rollout Manager)'''</big> The staged rollout managers:
##Collect all reports and may produce a summary report.
##Create a document in the EGI Doc server with a given ID, which will contain all reports for the staged rollout of that component, as well as the summary report.
##Insert a link to the Dec server ID of the reports.  
##Write the outcome '''&lt;ACCEPT|REJECT&gt;''' in a custom field.  
##Set the ticket status to '''resolved'''.  
#<big>'''(Staged Rollout Manager)'''</big> When the staged rollout child ticket is set to '''resolved''' the parent ticket is notified, and it should get the outcome and the doc server id of the reports.


* Two persons per SW stack should ideally compose the staged rollout managers group:
= Resources =
** Glite
** ARC
** UNICORE
** Globus
** Operational Tools


* The name of the file should be:
*The Staged Rollout process is supported by the RT ticketing system (see tickets in the '''staged-rollout''' queue).  
** Filename: '''ea-< NGI >-< Site-name >-< MW stack >-< component >-< version >'''.doc(odt)
*Report templates: each Early Adopter has to fill in a report (see the [https://documents.egi.eu/public/ShowDocument?docid=254 template] on DocumentDB.


* The '''staged rollout manager''' will provide a summary and the name of the file is:
= Naming conventions =
** Filename of summary: '''summary-< MW stack >-< component >-< version >'''.doc(odt)


All reports and the summary will be in: https://documents.egi.eu with a given ID, that will be referenced in the respective rt ticket.
*The EA team names are SSO groups containing the members of each team:  
**'''ea-&lt; NGI &gt;-&lt; Site-name &gt;'''


* The description in the document database should have the following naming convention:
*The custom fields needed in the '''staged-rollout''' queue are:
** '''Staged rollout < MW stack > < component > < version >'''
**Drops down box containing all EA teams, on the EGI SSO: possibility to select several teams, the button '''Save Changes''' notifies those teams and they will be added to the '''AdminCC''' field.
**Outcome of the staged rollout, drop down box with: '''&lt; ACCEPT | REJECT &gt;'''.
 
*The title of the ticket is of the form:
**'''“Staged Rollout &lt; SW stack-MajorVersion &gt; &lt; COMPONENT &gt; &lt; VERSION &gt; &lt; OS &gt; &lt; ARCH &gt;”'''
**Examples:
***'''Staged Rollout CA 1.38'''
***'''Staged Rollout EMI-1.0 SE-DPM_mysql 1.8.0-1 SL5 x86_64'''
 
*Two persons per SW stack should ideally compose the staged rollout managers group:
**Glite
**ARC
**UNICORE
**Globus
**Operational Tools
 
*The name of the file should be:
**Filename: '''ea-&lt; NGI &gt;-&lt; Site-name &gt;-&lt; MW stack &gt;-&lt; component &gt;-&lt; version &gt;'''.doc(odt)
 
*The '''staged rollout manager''' will provide a summary and the name of the file is:
**Filename of summary: '''summary-&lt; MW stack &gt;-&lt; component &gt;-&lt; version &gt;'''.doc(odt)
 
All reports and the summary will be in: https://documents.egi.eu with a given ID, that will be referenced in the respective rt ticket.
 
*The description in the document database should have the following naming convention:  
**'''Staged rollout &lt; MW stack &gt; &lt; component &gt; &lt; version &gt;'''


----
----
Back [[Staged-Rollout]]
Back [[Staged-Rollout]]

Revision as of 17:49, 19 April 2011

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security



New Software Release Workflow

The full description of the New Software Release Workflow (NSRW) includes all stages from software release by a Technology Provider to release for deployment in the EGI production infrastructure.

The remainder of this document describes the part of the workflow corresponding to the Staged Rollout phase.

Staged Rollout Workflow

The staged rollout start when the "RolloutProgress" custom field of RT ticket in the queue sw-rel changes from "InVerification" to "StageRollOut", this means that the SW component as passed the verification process, i.e. was "ACCEPTED" in the verification phase.This triggers the creation of a child ticket in the "staged-rollout" queue, where all the Staged Rollout process occurs.

It is assumed that the staged rollout repository is fixed for any given major release of any SW, this is publicly available in the repository and EGI wiki for Early Adopters. This state change triggers the following actions:

  1. The SW packages are moved from the InVerification repository to the StageRollOut repository.
  2. The sw-rel ticket creates a new child ticket in the staged-rollout queue.
    1. The ownership of the sw-rel ticket is changed to the SSO group sw-rel-sr.
  3. (Staged Rollout Manager) The staged rollout managers staged-rollout SSO group is notified when the child ticket in queue staged-rollout is created.
    1. The staged-rollout ticket should contain the links to:
      1. Release notes, contains information about install/upgrade and configuration.
      2. Bugs or issues fixed.
      3. Documentation.
    2. The status of the ticket is new.
  4. (Staged Rollout Manager) The queue staged-rollout has a custom field (dropped down) where the staged rollout managers select the EA teams to assign the staged rollout test.
    1. (Staged Rollout Manager) The status of the ticket is changed to open.
    2. (EA teams) Each EA team has to acknowledge the reception of the notification within 1 working day. Either by replying to the mail sent by the RT or directly in the ticket with:
      1. (EA teams) <accept|reject> <NGI>-<Site-name>
    3. (Staged Rollout Manager) The staged rollout manager will check the ticket and if there are no EAs accepting the staged rollout test, it will pool the early-adopters-XXX.mailman.egi.eu mailing lists, and other (s)he see’s fit to get other EA sites.
  5. (EA teams) The EA team has the option to put the service node into downtime in the GOCDB, special beta tag. This tag may be set only during the staged rollout phase, if/when the component is release into production, this tag (or downtime), should be removed from the gocdb.
  6. (EA teams) The EA teams do the staged rollout: install/upgrade, configure, and some tests as they see fit.
    1. (EA teams) If the EA finds problems or issues, either they are clarified within the ticket by the staged rollout managers and other EA teams, OR , a GGUS ticket should be opened.
    2. (EA teams) If a GGUS ticket is opened, this ticket should be assigned to the DMSU support unit, which will then route it to the technology providers as they see fit.
    3. (EA teams) A link to the GGUS ticket should be created in the staged rollout ticket.
  7. (EA teams) The service should ideally be exposed into production load/environment and users. This period may last between 5 to 7 days, but may be extended depending on the cases.
  8. (EA teams) Each EA team should fill the staged rollout templates after the last point, and attach it to the staged-rollout ticket:
    1. (EA teams) The report should contain as much information as possible, specially the correctness of the release notes, test that have been preformed, and possible metrics when the service is exposed to production (like number of jobs per day, or number of transfers, what VOs are configured for that service, etc.)
    2. (EA teams) The name of the file should be:
      1. ea-<NGI>-<Site-name>-<MW stack>-<component>-<version>.EXT (doc, docx, odt)
  9. (Staged Rollout Manager) The staged rollout managers:
    1. Collect all reports and may produce a summary report.
    2. Create a document in the EGI Doc server with a given ID, which will contain all reports for the staged rollout of that component, as well as the summary report.
    3. Insert a link to the Dec server ID of the reports.
    4. Write the outcome <ACCEPT|REJECT> in a custom field.
    5. Set the ticket status to resolved.
  10. (Staged Rollout Manager) When the staged rollout child ticket is set to resolved the parent ticket is notified, and it should get the outcome and the doc server id of the reports.

Resources

  • The Staged Rollout process is supported by the RT ticketing system (see tickets in the staged-rollout queue).
  • Report templates: each Early Adopter has to fill in a report (see the template on DocumentDB.

Naming conventions

  • The EA team names are SSO groups containing the members of each team:
    • ea-< NGI >-< Site-name >
  • The custom fields needed in the staged-rollout queue are:
    • Drops down box containing all EA teams, on the EGI SSO: possibility to select several teams, the button Save Changes notifies those teams and they will be added to the AdminCC field.
    • Outcome of the staged rollout, drop down box with: < ACCEPT | REJECT >.
  • The title of the ticket is of the form:
    • “Staged Rollout < SW stack-MajorVersion > < COMPONENT > < VERSION > < OS > < ARCH >”
    • Examples:
      • Staged Rollout CA 1.38
      • Staged Rollout EMI-1.0 SE-DPM_mysql 1.8.0-1 SL5 x86_64
  • Two persons per SW stack should ideally compose the staged rollout managers group:
    • Glite
    • ARC
    • UNICORE
    • Globus
    • Operational Tools
  • The name of the file should be:
    • Filename: ea-< NGI >-< Site-name >-< MW stack >-< component >-< version >.doc(odt)
  • The staged rollout manager will provide a summary and the name of the file is:
    • Filename of summary: summary-< MW stack >-< component >-< version >.doc(odt)

All reports and the summary will be in: https://documents.egi.eu with a given ID, that will be referenced in the respective rt ticket.

  • The description in the document database should have the following naming convention:
    • Staged rollout < MW stack > < component > < version >

Back Staged-Rollout

Retrieved from "https://wiki.egi.eu/w/index.php?title=Staged_Rollout_process&oldid=15844"