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 Software Provisioning"

From EGIWiki
Jump to navigation Jump to search
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Tech menubar}}
{{Tech menubar}} {{SWProv menubar}}  
{{Tech Main submenu}}
{{TOC_right}}  
{{TOC_right}}


EGI's Software Provisioning activity governs and executes two main processes through which EGI ensures that deployed software
EGI's UMD Provisioning activity governs and executes two main processes:
* Is constantly adapted to changing needs of the EGI Community by implementing new features and phasing out features and components that are no longer needed. and
* maintains and improves its quality as defined by EGI.


#'''Software Provisioning Process:''' That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting.
#'''UMD Release Process''': That collects tested Products per Platform and Architecture (PPAs) into UMD Releases
== Software Provisioning Process ==


The following picture depicts the processes as described:
The Software Provisioning process consists of


[[File:Provisioning workflow.png]]
#'''Software Delivery''' – Technology Providers submit new software releases<br>
#'''Software Assessment''' – through Quality Assurance &amp; Staged Rollout
#'''Reporting '''– inform TP about outcome of the software provisioning process


=== Management boards ===
'''Software Delivery''' this is the process according to which Technology Providers submit through GGUS new software releases. Software delivery is performed using one of the three different user interfaces available, i.e. a web form, e-mailing and a web service interface, that create tickets including all the necessary information about the software delivered in order to be processed. GGUS forwards the tickets to RT creating one RT ticket per Product per Platform and Architecture (PPA).<br>


* '''Technology Coordination Board (TCB)''' <br>The TCB governs the overall process of technology evolution through negotiating formal agreements with Technology Providers who are responsible for the constant delivery of software according to the requirements developed and specified by the EGI Community (End users ans Operations). Members of the TCB are members of the executive management of EGI.eu, representing the EGI User Community, the EGI Operations Community, and EGI Software Provisioning activity. Furthermore, key representatives of affiliated Technology Providers partake meetings of the TCB providing input, guidance and feedback from software engineering experts within their teams.
<br>  
* '''Quality Assurance Task Force (QATF)''' <br>The Quality Assurance Task Force provides a forum for specialists in Quality Assurance from EGI and affiliated Technology Providers as a regular forum for continuous review and improvements of the Quality Criteria defined within EGI.
* '''Automation Task Force (ATF)''' <br>The Automation Task Force coordinates the technical processes and integration points for Technology Providers and EGI's technical implementation of the Software Provisioning process. Experts in process automation, repository maintenance and software provisioning from EGI and its affiliated Technology Providers define the processes and artifacts required to sustain continuous software provisioning on EGIs production infrastructure.


=== Reviews ===
#After the first successful release, TP should request the subscription to the UMD Release team
#Communication Channels of new updates:
#*E-mail to URT team
#*Update the information on the URT meeting agendas
#Information needed for each update:
#*Product Name &amp; Version
#*Release Notes as:<br>
#**What’s New – bug fixes, new features
#**Installation &amp; Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
#**List of Packages to be updated
#**Location where the packages are available:<br>
#***TP repositories<br>
#***APP DB <br>


On occasion, processes are reviewed, and based on the analysis actions are defined to improve process, artifacts or both. The following is a list of review reports conducted:
'''Software Assessment''' is done in two phases


{| class="wikitable" style="border:1px solid black;" cellpadding="5" cellspacing="0"
#Quality Assurance
|- style="background-color:darkgray;"
#Stage Rollout
! style=" border-bottom:1px solid black;" | Date
 
! style=" border-bottom:1px solid black;" | Title
<br>
! style=" border-bottom:1px solid black;" | DocDB link
 
|-
<br>
| 19. 02. 2011
 
| Review of Software Provisioning Process execution in EGI
[[Image:SW-Assesment.png|800px|SW-Assesment.png]]
| align="center" | [https://documents.egi.eu/secure/ShowDocument?docid=374 374]
 
|- style="background:lightgray;"
'''Reporting''' this is the last process that reports back to Technology providers the outcome of the software provisioning process.
|
 
|
<br>
|
 
|}
[[Image:SW-Reporting.png|800px|SW-Reporting.png]]
 
= The software provisioning process, step by step =
 
[[File:UMD_process-v1.png|900px]]
 
# The product team submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information
#* Product release and version number
#* Link to the release notes
#* Full list of packages that compose the release, and that need to be released in UMD
# The product release is injected in the EGI SW provisioning infrastructure
#* One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release
#* The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket
#* The status of the product release will be tracked in RT
#* This action must be closed in '''5 working days''' by the UMD team
# The RT ticket is in "Unverified" status
#* This is the "waiting line" for the verification process
#* RT cannot stay longer than '''one month''' in the "Unverified" status
#* After a month if the verification has not started the RT ticket will be updated with an explanation for the delay and the status will be changed to "Delayed"
#* Product team (using the contact in the Product ID card) will be informed of the delay, with the reasons that caused the delay
#* Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely. 
# The RT ticket is in "Verification" status
#* This means that the UMD team is verifying the product in the testbed.
#* An RT ticket cannot stay longer than '''one week''' in verification
#* After one week, if it has not been verified it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
# Product is in "Staged Rollout" Status
#* The product is announced to the early adopters testing in staged rollout the product.
#* #* RT cannot stay longer than '''one month''' in the "Staged Rollout" status
#* After one month, if it has not been tested in staged rollout it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
# After the staged rollout product is ready to be included in the next UMD release
#* The overall process should not take longer than *two months*, without the PT be informed of any delays
 
 
[[Category:Technology]]

Latest revision as of 17:31, 3 March 2017

Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary


Software Provisioning menu: Software Provisioning Process UMD Release Process Quality Assurance UMD Staged Rollout




EGI's UMD Provisioning activity governs and executes two main processes:

  1. Software Provisioning Process: That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting.
  2. UMD Release Process: That collects tested Products per Platform and Architecture (PPAs) into UMD Releases

Software Provisioning Process

The Software Provisioning process consists of

  1. Software Delivery – Technology Providers submit new software releases
  2. Software Assessment – through Quality Assurance & Staged Rollout
  3. Reporting – inform TP about outcome of the software provisioning process

Software Delivery this is the process according to which Technology Providers submit through GGUS new software releases. Software delivery is performed using one of the three different user interfaces available, i.e. a web form, e-mailing and a web service interface, that create tickets including all the necessary information about the software delivered in order to be processed. GGUS forwards the tickets to RT creating one RT ticket per Product per Platform and Architecture (PPA).


  1. After the first successful release, TP should request the subscription to the UMD Release team
  2. Communication Channels of new updates:
    • E-mail to URT team
    • Update the information on the URT meeting agendas
  3. Information needed for each update:
    • Product Name & Version
    • Release Notes as:
      • What’s New – bug fixes, new features
      • Installation & Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
      • List of Packages to be updated
      • Location where the packages are available:
        • TP repositories
        • APP DB

Software Assessment is done in two phases

  1. Quality Assurance
  2. Stage Rollout



SW-Assesment.png

Reporting this is the last process that reports back to Technology providers the outcome of the software provisioning process.


SW-Reporting.png

The software provisioning process, step by step

UMD process-v1.png

  1. The product team submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information
    • Product release and version number
    • Link to the release notes
    • Full list of packages that compose the release, and that need to be released in UMD
  2. The product release is injected in the EGI SW provisioning infrastructure
    • One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release
    • The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket
    • The status of the product release will be tracked in RT
    • This action must be closed in 5 working days by the UMD team
  3. The RT ticket is in "Unverified" status
    • This is the "waiting line" for the verification process
    • RT cannot stay longer than one month in the "Unverified" status
    • After a month if the verification has not started the RT ticket will be updated with an explanation for the delay and the status will be changed to "Delayed"
    • Product team (using the contact in the Product ID card) will be informed of the delay, with the reasons that caused the delay
    • Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.
  4. The RT ticket is in "Verification" status
    • This means that the UMD team is verifying the product in the testbed.
    • An RT ticket cannot stay longer than one week in verification
    • After one week, if it has not been verified it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
  5. Product is in "Staged Rollout" Status
    • The product is announced to the early adopters testing in staged rollout the product.
    • #* RT cannot stay longer than one month in the "Staged Rollout" status
    • After one month, if it has not been tested in staged rollout it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
  6. After the staged rollout product is ready to be included in the next UMD release
    • The overall process should not take longer than *two months*, without the PT be informed of any delays