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
 
(36 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{TOC_right}}
{{Tech menubar}} {{SWProv menubar}}
{{TOC_right}}  


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


The Quality Assurance unit in EGI defines and executes the processes of
#'''Software Provisioning Process:''' That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting.
* structuring, defining and assurance of technical accuracy of Quality Criteria
#'''UMD Release Process''': That collects tested Products per Platform and Architecture (PPAs) into UMD Releases
* evolving Quality Criteria from a current set to a future set of criteria valid for assurance and control by Technology Providers
== Software Provisioning Process ==


=== Structure and Definition of Quality Criteria ===
The Software Provisioning process consists of  


EGI's Quality Critera are organised in a set of documents. The organisation of Quality Criteria follows the layout of the UMD Roadmap version for which the Quality Criteria [[https://wiki.egi.eu/wiki/EGI_Technology#Evolution_of_Quality_Criteria are valid]].
#'''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


One document in any given set of Quality Criteria defines ''Generic Quality Criteria'', whereas the remaining documents define the ''Specific Quality Criteria''.
'''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>


**Generic Quality Criteria** apply to all Products delivered to EGI by a Technology Provider. However, some Generic Quality Criteria may not apply to a specific Product because the scope of the Product falls out of the coverage of the pertinent Generic Quality Criteria. The Quality Control team in EGI advises Technology Providers which Generic Quality Criteria apply to Products they wish to make available to EGI.
<br>


**Specific Quality Criteria** apply to all Products delivered to EGI that implement a specific UMD Capability. Conversely, if a Product implements more than one Capability at once, then ''all'' Specific Quality Criteria of all implemented Capabilities apply to the given Product.
#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>


=== Evolution of Quality Criteria ===
'''Software Assessment''' is done in two phases


It is a well-proven fact in Software Engineering that user requirements for any given piece of software change over time. So, as requirements change, so must the software designed to satisfy these requirements. Consequently, Quality Criteria by which the quality of the software is assessed that is verified for production infrastructure availability, must evolve over time, too.
#Quality Assurance
#Stage Rollout


With change of Quality Criteria come multiple sets of Quality Criteria. To deliver software that matches EGI's quality demand, Technology Providers must know well in advance which set of Quality Criteria are in effect at any given point in time.
<br>


<br>


The following rules define the process of Quality Criteria validity:
[[Image:SW-Assesment.png|800px|SW-Assesment.png]]  
* A set of Quality Criteria covers the complete UMD Capabilities.
* A set of Quality Criteria are valid for 6 calendar months, following the [[https://wiki.egi.eu/wiki/WP5:_Provisioning_the_Software_Infrastructure_(SA2)#Deliverables UMD Roadmap publication schedule]] with an offset of one month.
* A set of Quality Criteria is stored in EGI's document database as a set of documents grouped in one storage location.
* A set of Quality Criteria has a shared version, e.g. "QC-1"
* At most one set of Quality Criteria is valid at any given point in time marked "FINAL" in EGI's document database.
* There may be more than one set of Quality Criteria in "DRAFT" status, marked as such in the document database.
* As time passes, FINAL sets of Quality Criteria may become "DEPRECATED" by the next version of Quality Criteria.
* All DEPRECATED sets of Quality Criteria are kept publicly available for reference.


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


Quality Criteria may evolve to reflect changing user requirements. The process of evolution is captured as follows:
<br>
# Anyone interested in the Quality Criteria definition may review the documents, at any given point in time.
# Feedback and requests for change must be given through the appropriate channels associated with the reviewer's affiliation
## Reviews and comments from the resource operation communities must be given through the OMB
## Reviews and comments from the end user communities must be given, via the VRCs, to the UCB
# UCB and OMB are collating and prioritising the reviews and comments, and discuss them at regular TCB meetings.
# The TCB decides upon the changes, and in which DRAFT version of the Quality Criteria they shall be reflected.


== Quality Control ==
[[Image:SW-Reporting.png|800px|SW-Reporting.png]]


Quality Control in EGI is conducted in a two-step process, accompanied with proactive dissemination and support for Technology Providers.
= The software provisioning process, step by step =


== Software Provisioning ==
[[File:UMD_process-v1.png|900px]]


== 2nd line support: Distributed Middleware Support Unit ==
# 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


== Glossary ==


{| class="sortable" style="border:1px solid black;" cellpadding="5" cellspacing="0"
[[Category:Technology]]
|-style="background: lightgray;"
! style="border-bottom:1px solid black;" | Term
! style="border-bottom:1px solid black;" | Description
|-
|style="border-bottom:1px solid black;" | (UMD) Capability
|style="border-bottom:1px solid black;" | A Capability is scoped around well known and well-defined activities that are sufficiently disparate, independent, and fulfil a discrete task in a higher-level orchestrated sequence of actions taken by the user (manually or automated) in order to reach the aspired goal. Capabilities may depend on the presence of another Capability. Appliances, however, SHOULD NOT depend on each other to avoid technical dependencies and vendor lock-in.
|-
|style="border-bottom:1px solid black;" | Appliance
|style="border-bottom:1px solid black;" | An Appliance is the technical implementation of a Capability. An Appliance may be delivered in a single, monolithic Package, or it may be delivered as a set of components that are grouped into a set of Packages. In the latter case all packages must be installed to provide the complete Appliance.
|-
|style="border-bottom:1px solid black;" | Package
|style="border-bottom:1px solid black;" | A Package is a structured software unit suitable for automated installation on a computer. A Package may specify dependencies on other packages, so that either a specific version of that package, or a minimum version of that package may satisfy that dependency.
|-
|style="border-bottom:1px solid black;" | Product
|style="border-bottom:1px solid black;" | A Product is a solution delivered by Technology Providers to EGI and provides the functionality for one, sometimes more Capabilities ''as one single, undividable unit''. Consequently, a Product may comprise of one or more Appliances.
|-
|style="border-bottom:1px solid black;" | Primary Package
|style="border-bottom:1px solid black;" | A Product consists of a well-defined set of specific packages, each in a specific version. Different versions (whether major, minor, or revision) of the same Product may share a subset of packages of the same version, that do not change between the compared versions.
|-
|style="border-bottom:1px solid black;" | Secondary Package
|style="border-bottom:1px solid black;" | A Secondary Package is a Package that is resolved from dependency declarations within a Package, that sources either from the Technology Provider's own Repository, or from any additional repository except OS distribution repositories. (Note: EPEL is an example of such a repository that is not an OS repository.)
|}

Latest revision as of 18: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
Retrieved from "https://wiki.egi.eu/w/index.php?title=EGI_Software_Provisioning&oldid=93488"