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 Component Delivery"

From EGIWiki
Jump to navigation Jump to search
Line 30: Line 30:
To become included in [https://wiki.egi.eu/wiki/UMD_Release_Team UMD Release Team (URT)] Technology provider should provide following information:<br>  
To become included in [https://wiki.egi.eu/wiki/UMD_Release_Team UMD Release Team (URT)] Technology provider should provide following information:<br>  


#Name of the Product team  
#'''Name '''of the Product team  
#Contacts (support email address, web site address)  
#'''Contacts '''(support email address, web site address)  
#Name and contact details of the Component Development Team Leader  
#Name and contact details of the Component Development '''Team Leader'''
#Description of the Component/Purpose<br>
#'''Description''' of the Product/Purpose<br>  
#'''Release channels''' for the product:
#*where to find the packages and their updates
#*packages should be provided as rpms for SL5 &amp; 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
#'''Documentation '''references – installation &amp; configuration guides, release notes
#Which releases, '''versions''', are going to be released in UMD and with which support calendar
#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.
 
 


Please read: [[UMD Release Team#How_to_join_URT|'''How to join''']]  
Please read: [[UMD Release Team#How_to_join_URT|'''How to join''']]  
Line 46: Line 56:


<br>  
<br>  
• Information on the products and product team to be reported in: https://wiki.egi.eu/wiki/URT:UMD_products_ID_cards o release channels for the product  <br>


= Ongoing activities<br>  =
= Ongoing activities<br>  =

Revision as of 11:34, 23 March 2015

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





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 become included in UMD Release Team (URT) 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 Product/Purpose
  5. Release channels for the product:
    • where to find the packages and their updates
    • packages should be provided 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
  6. Documentation references – installation & configuration guides, release notes
  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 asEarly Adopters in the staged rollout phase.


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


• Information on the products and product team to be reported in: https://wiki.egi.eu/wiki/URT:UMD_products_ID_cards o release channels for the product 

Ongoing activities

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

Software Deliver

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 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
    • 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.

Customer relationship management

Goal: Establish and maintain a good relationship with customers receiving service

The Provider interacts with EGI.eu, primarily with OMB, the main customer of the operational tools.

Interactions between EGI.eu TPs are guaranteed through periodic phone conferences and face to face meetings (URT). A dedicated mailing list is available as well: urt-discuss@mailman.egi.eu

Interactions with customers are guaranteed through periodic OMB meetings and (if needed) dedicated Advisory Groups. The AG mandate is to help the Provider in requirement prioritization and releasing process of the Component. AG can provide forums to discuss the Component evolution that meets the expressed needs of the EGI community. It has representation from the all end users groups depending on the Component.