Difference between revisions of "EGI Software Component Delivery"

From EGIWiki
Jump to: navigation, search
(Ongoing activities)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Tech menubar}}  
 
{{Tech menubar}}  
{{SWProv_menubar}}
+
{{TOC_right}}
 
 
{{TOC_right}}
 
  
 
<br> EGI's UMD Provisioning activity governs and executes two main processes:  
 
<br> EGI's UMD Provisioning activity governs and executes two main processes:  
Line 29: Line 27:
 
= Initial activities - Joining UMD Release Team<br>  =
 
= Initial activities - Joining UMD Release Team<br>  =
  
To be included in [https://wiki.egi.eu/wiki/UMD_Release_Team UMD Release Team (URT)] the interested Technology Provider should provide following information:<br>  
+
To be included in [https://wiki.egi.eu/wiki/URT UMD Release Team (URT)] the interested Technology Provider should provide following information:<br>  
  
 
#'''Name '''of the Product team  
 
#'''Name '''of the Product team  
Line 44: Line 42:
 
#Communicate if TP have information on sites already deploying the software that can be interested in acting as '''Early Adopters''' in the staged rollout phase.
 
#Communicate if TP have information on sites already deploying the software that can be interested in acting as '''Early Adopters''' in the staged rollout phase.
  
All information will be included into [[URT:UMD products ID cards|UMD products ID card]]  
+
All information will be included into [[UMD_products_ID_cards|UMD products ID card]]  
  
 
<br>  
 
<br>  
Line 80: Line 78:
 
Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.  
 
Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.  
  
=== Software Deliver<br>  ===
+
=== Software Delivery<br>  ===
  
 
'''Goal: Submitting new software releases'''  
 
'''Goal: Submitting new software releases'''  
Line 99: Line 97:
 
#***[https://appdb.egi.eu/browse/software AppDB]
 
#***[https://appdb.egi.eu/browse/software AppDB]
  
<br>  
+
<br>
  
 
== '''Software Assessment'''  ==
 
== '''Software Assessment'''  ==
Line 108: Line 106:
 
#*[[EGI Quality Criteria Definition|Quality Criteria definition ]]– definition and updates of the Quality Criteria used in the Software Verification step  
 
#*[[EGI Quality Criteria Definition|Quality Criteria definition ]]– definition and updates of the Quality Criteria used in the Software Verification step  
 
#*Quality Criteria Verification  
 
#*Quality Criteria Verification  
#**Packages are pulled from the TP into UMD repos (unverified) and the Verification team starts he verification of the info provided by the TP, apply QC, general and specific defined for respective product  
+
#**Packages are pulled from the TP repositories into UMD repos (unverified) and the Verification team starts he verification of the info provided by the TP, apply QC, general and specific defined for respective product  
 
#**A [https://documents.egi.eu/document/417 Verification Report] is provided (in DocDB) for the Staged Rollout site  
 
#**A [https://documents.egi.eu/document/417 Verification Report] is provided (in DocDB) for the Staged Rollout site  
 
#**TP are informed regarding issues discovered, workarounds needed – through GGUS  
 
#**TP are informed regarding issues discovered, workarounds needed – through GGUS  
#*[[Staged-Rollout|Staged Rollout ]]  
+
#[[Staged-Rollout|Staged Rollout ]]  
 
#**Successful verified products are deployed on Early Adopters sites for testing in a production environment before the inclusion in the UMD production repositories.  
 
#**Successful verified products are deployed on Early Adopters sites for testing in a production environment before the inclusion in the UMD production repositories.  
 
#**Reports with the results of this testing phase are recorded in [https://documents.egi.eu/public/ShowDocument?docid=254 DocDB]
 
#**Reports with the results of this testing phase are recorded in [https://documents.egi.eu/public/ShowDocument?docid=254 DocDB]
  
<br>  
+
<br>
  
 
== Support  ==
 
== Support  ==
Line 123: Line 121:
 
*via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.  
 
*via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.  
 
*(for incidents) According to declared level of [[FAQ GGUS-QoS-Levels|quality of support&nbsp;]]&nbsp;  
 
*(for incidents) According to declared level of [[FAQ GGUS-QoS-Levels|quality of support&nbsp;]]&nbsp;  
*Support is provided in '''English'''<br>
+
*Support is provided in '''English'''
 +
 
 +
<br>
  
 
== Information Security management  ==
 
== Information Security management  ==
  
'''<br>'''
 
  
 
The following rules for information security and data protection apply:<br>•&nbsp;&nbsp;&nbsp; The Provider must define and abide by an information security and data protection policy related to the service being provided. <br>•&nbsp;&nbsp;&nbsp; This must meet all requirements of any relevant [http://www.egi.eu/about/policy/policies_procedures.html EGI policies or procedures] and also must be compliant with the relevant national legislation.<br><br>  
 
The following rules for information security and data protection apply:<br>•&nbsp;&nbsp;&nbsp; The Provider must define and abide by an information security and data protection policy related to the service being provided. <br>•&nbsp;&nbsp;&nbsp; This must meet all requirements of any relevant [http://www.egi.eu/about/policy/policies_procedures.html EGI policies or procedures] and also must be compliant with the relevant national legislation.<br><br>  

Latest revision as of 10:48, 19 February 2019

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




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


Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:

  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


Small workflow diagram representing status of products through the Software Provisioning Process:

Software Provisioning Process.png



Initial activities - Joining UMD Release Team

To be included in UMD Release Team (URT) the interested Technology Provider should provide following information:

  1. Name of the Product team
  2. Contacts (support email address, web site address)
  3. Name and contact details of the Component Development Team Leader
  4. Description of the Component/Product and its Purpose
  5. Release channels for the product:
    • where to find the packages and their updates
    • components/products should be provided in the native packaging format of the OSs supported in UMD (i.e. as rpms for SL5 & SL6, and deb packages for Debian)
    • packages should have dependencies on packages provided by the respective OS and EPEL (for Fedora/SL family)
    • any other external dependencies should be also provided or referenced as being provided by other Technology Providers part of the URT team
  6. Documentation references – installation & configuration guides, release notes, known issues and troubleshooting, reference cards
  7. Which releases, versions, are going to be released in UMD and with which support calendar
  8. Communicate if TP have information on sites already deploying the software that can be interested in acting as Early Adopters in the staged rollout phase.

All information will be included into UMD products ID card


To send join request please read: How to join


With the help of the EGI UMD Release Team (URT), the following steps need to be performed:

  1. Create GGUS Support Unit to receive and handle incidents (define level of quality of support)
  2. Agree on Technical Provider Underpinning Agreement (TP UA) with EGI.eu
  3. Subscribe to the UMD Release team mailing list


First release

This section describe workflow of adding first release: 

  1. First packages are pulled into the untested area of the UMD repositories
  2. UMD team starts the first verification, involving the TP, in order to:
    • understand how deployment should be done
    • check the present Quality Criteria definitions and determine if the common criteria apply or not, if specific criteria are needed for the new products
    • update the Verification and Staged Rollout Reports template, if needed
    • provide workarounds or new versions of the packages if issues are discovered
  3. after a successful verification packages are moved in the testing area of the UMD repos and the Early Adopter sites/sites are contacted for deploying the new release, and after a grace period of few days, to provide the Staged-Rollout report with the results of these testing phase.
    • If issues are discovered – if possible workarounds will be documented, otherwise the product is rejected and a new version should be provided (fixing the issues)
  4. After a successful Staged-Rollout packages are moved in the UMD Store area, and will become part of the next available UMD release.



Ongoing activities

Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.

Software Delivery

Goal: Submitting new software releases


  1. Communicate information about new update
  2. 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:


Software Assessment

Goal: Assessment through Quality Assurance & Staged Rollout

  1. Quality Assurance – through
    • Quality Criteria definition – definition and updates of the Quality Criteria used in the Software Verification step
    • Quality Criteria Verification
      • Packages are pulled from the TP repositories into UMD repos (unverified) and the Verification team starts he verification of the info provided by the TP, apply QC, general and specific defined for respective product
      • A Verification Report is provided (in DocDB) for the Staged Rollout site
      • TP are informed regarding issues discovered, workarounds needed – through GGUS
  2. Staged Rollout
      • Successful verified products are deployed on Early Adopters sites for testing in a production environment before the inclusion in the UMD production repositories.
      • Reports with the results of this testing phase are recorded in DocDB


Support

Support should be provided:

  • via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
  • (for incidents) According to declared level of quality of support  
  • Support is provided in English


Information Security management

The following rules for information security and data protection apply:
•    The Provider must define and abide by an information security and data protection policy related to the service being provided.
•    This must meet all requirements of any relevant EGI policies or procedures and also must be compliant with the relevant national legislation.