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


{{TOC_right}}
<br> EGI's UMD Provisioning activity governs and executes two main processes:


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


'''Goal: Introducing new Component.'''
<br>  
<br>Every new Technological Provider (TP) will join the [https://wiki.egi.eu/wiki/UMD_Release_Team UMD Release Team (URT)].
<br>Every new Component will be introduced in UMD contacting the [https://wiki.egi.eu/wiki/UMD_Release_Team URT] providing following data:


#Name of the Component
Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:
#Contacts (support email address, web site address)
#Name and contact details of the Component Development Team Leader
#Description of the Component/Purpose
#License<br>


With the help of the EGI UMD Release Team (URT), the following steps need to be performed:
#'''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


#Registration in GOCDB under EGI.eu NGI
<br>  
#Create category in "Requirements" queue in EGI RT tracker and RT dashboard to receive and handle service requests
#Create GGUS Support Unit to receive and handle incidents (define level of quality of support - default: Medium)
#Negotiate and sign Technical Provider Underpinning Agreement (TP UA) https://documents.egi.eu/document/2282 with EGI.eu<br>  
#Create wiki entry for the tool with relevant information
#*Component name
#*Category, Short description of the Component
#*URL
#*Component Contact for EGI.eu
#*EGI.eu Contact for Component
#*GGUS Support Unit
#*GOCDB entry
#*link to related TP UA
#*link to documentation
#*license
#*Provider name
#*link to source code
#*Change management:
#**link to EGI RT dashboard for the tool
#**internal bug/task tracking facilities (if any)
#**link to Advisory Group (AG) team (if any)<br>
#*Release and Deployment management:
#**Release channels
#***where to find packages/updates, for which architectures, which formats
#***dependencies on OS/EPEL/other external repositories
#**Release schedule
#**Release notes
#**(if applicable) Roadmap
#**URL of test instance
#**(if applicable) list of sites that can be interested in acting as '''Early Adopters''' in the Staged Rollout phase


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


= Ongoing activities<br>  =
[[Image:Software Provisioning Process.png|300px|Software Provisioning Process.png]]


== Change management <br> ==
<br>  


'''Goal:&nbsp;To ensure changes are planned, approved, implemented and reviewed in a controlled manner to avoid adverse impact of changes to services or the customers receiving services. '''
<br>


[[Image:CM.png|600px|CM.png]]
= Initial activities - Joining UMD Release Team<br>  =


=== Record  ===
To be included in [https://wiki.egi.eu/wiki/URT UMD Release Team (URT)] the interested Technology Provider should provide following information:<br>


#'''EGI recording system''' is [http://rt.egi.eu EGI RT]&nbsp;
#'''Name '''of the Product team
#'''EGI&nbsp;user''' are instructed to submit changes requests in EGI RT.
#'''Contacts '''(support email address, web site address)
#If the Component has '''other customers than EGI,''' the Provider will inform EGI about submitted change requests from other customers.
#Name and contact details of the Component Development '''Team Leader'''  
#The following information will be provided:
#'''Description''' of the Component/Product and its Purpose<br>
#*Product Name and Version
#'''Release channels''' for the product:
#*What’s  New (bug  fixes,  new  features...)
#*where to find the packages and their updates
#*Installation  &  Configuration  instructions (what  needs  to  be done  to correctly  update  the Component on the production infrastructure
#*components/products should be provided in the native packaging format of the OSs supported in UMD (i.e. as rpms for SL5 &amp; SL6, and deb packages for Debian)  
#*List of Packages to be updated
#*packages should have dependencies on packages provided by the respective OS and EPEL (for Fedora/SL family)
#*Location where the packages are available (TP repositories, AppDB...)
#*any other external dependencies should be also provided or referenced as being provided by other Technology Providers part of the URT team
#Minimum set of statuses of entry
#'''Documentation '''references – installation &amp; configuration guides, release notes, known issues and troubleshooting, reference cards
#*New - newly recorded in system
#Which releases, '''versions''', are going to be released in UMD and with which support calendar
#*Accepted - accepted by AG/OMB
#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.
#*Rejected - rejected by AG/OMB
#*In progress/Open - TP is working on the request<br>
#*Resolved - released
#*Stalled - on hold


=== Classify<br>  ===
All information will be included into [[UMD_products_ID_cards|UMD products ID card]]


#All change requests should be '''classified in consistent manner'''. Classification in EGI RT is based on the Component the request is related to. <br>  
<br>  
#TP should define list of '''standard change '''requests (a Change that is recurrent, well known, has been proceduralized to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authority is effectively given in advance of implementation.). Standard change request '''doesn't need approval''' to be implemented.
#'''Emergency change''' for the Component are the highest priority change related to '''security vulnerability '''and can be implemented '''without approval '''but will be '''subject of post-review'''.


=== Assess and Approve<br>  ===
To send join request please read: [[UMD Release Team#How_to_join_URT|'''How to join''']]


#Each change request should be commented by the TP with assessment of work needed to implement change.
<br>  
#'''Every change''' which is not a standard change or emergency change '''should be assessed '''(prioritized)'''and approved '''internally, in the URT and with OMB.
#Where needed dedicated [[AG|Advisory Group]] can be set up. The AG mandate is to help the TP in requirement prioritization and releasing process of the Component. AG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool.<br>  
#Minimum set of value for prioritization:
#*None (in RT - 0)
#*Low (in RT - 1)
#*Normal (in RT - 2)
#*High (in RT - 3)
#*Immediate/emergency (in RT - 4)


=== Implement, release and deploy<br>  ===
With the help of the EGI UMD Release Team (URT), the following steps need to be performed:


Phase which take place in [https://wiki.egi.eu/wiki/EGI_Software_Component_Delivery#Release_and_deployment_management Release and deployment management] (see below).<br>  
#Create GGUS Support Unit to receive and handle incidents (define [[FAQ GGUS-QoS-Levels|level of quality of support]])
#Agree on [https://documents.egi.eu/document/2282 Technical Provider Underpinning Agreement] (TP UA) with EGI.eu<br>  
#Subscribe to the UMD Release team mailing list


=== Review<br> ===
<br>  


#Every release is subject to '''post-implementation review'''. Within one week customers are providing feedback answering to following questions:
== First release<br> ==
#*Were release notes and documentation sufficient?
#*Is the tool working as expected?<br>


== Release and deployment management  ==
This section describe workflow of adding first release:&nbsp;


'''Goal: To bundle changes to release, so that these changes can be tested and deployed to the production environment together.'''  
#First packages are pulled into the '''untested area''' of the UMD repositories
#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
#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)
#After a '''successful Staged-Rollout '''packages are moved in the '''UMD Store area''', and will become part of the next available UMD release.


[[Image:RnDM.png|700px|RnDM.png]]
<br> <br>


=== Plan Release ===
= Ongoing activities<br> =


#Release schedules should be defined - the frequency of releases (eg. every 1-2 month).<br>
Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.  
#Scope of every release should be defined.
#Release should be planned in a away that OMB can be informed in at least one week time in advance.
#*all planned releases should be presented during the OMB meetings and URT meetings prior to their release to production
#*emergency releases should be presented at the first available OMB meeting and URT meeting, post-release.


=== Build Release<br>  ===
=== Software Delivery<br>  ===


#Due to the open-source nature of the developed software, each Component should have/use a '''publicly available code repository,''' like SVN, CVS, GIT
'''Goal: Submitting new software releases'''  
#*preferred Software Versioning Control system - GITHUB (https://github.com/)
#All new releases should correspond to a new '''tag''' in the SVC
#*the Component should be packaged in an OS native format (e.g. rpm, deb)
#**packaging standards and policies should be followed (ex: [http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS], [https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies EPEL-GuidelinesAndPolicies], [https://www.debian.org/doc/debian-policy/ Debian Policies])
#Distribution
#**new releases should be distributed as binaries through the UMD repository


=== Test Release  ===
<br>


#Testing of the software, prior to its release, is a '''responsibility of the Provider.'''
#Communicate information about new update
#Where dedicated '''AG''' exists it can be involved in the testing activity.
#*Send e-mail to URT team
#'''Major or particularly important releases''' should pass acceptance testing performed by customer representatives
#*Update the information on the [[URT meetings agendas|URT meeting agendas]]
#When the development phase of a new release is completed an announced it should be shared in the URT and to all the actors that should be involved in the release testing (AGs). The announcement should contain:  
#Information needed for each update:
#*release notes, containing changelog, installation &amp; configuration steps to apply the update, any known issues
#*Product Name &amp; Version
#*documentation links
#*Release Notes as:  
#*detailed test plan<br>
#**What’s New – bug fixes, new features
#*all the information needed by the [https://wiki.egi.eu/wiki/EGI_Quality_Criteria_Dissemination conformance criteria] set by the SA2 activity for the software providers.
#**Installation &amp; Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
#*the expected release date and the kind of testing will depend on each specific release and on its importance.
#**List of Packages to be updated
#'''If a test fails''' a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the development team if no other components or services are affected.
#**Location where the packages are available:
#***TP repositories
#***[https://appdb.egi.eu/browse/software AppDB]


=== Document  ===
<br>


#'''The Provider is responsible for creation and maintenance of documentations''', instructions and manuals related to the Component in collaboration with EGI Operations team.
== '''Software Assessment''' ==
#Before each release documentation should be checked and updated when/where needed.<br>


=== Inform  ===
'''Goal: Assessment through Quality Assurance &amp; Staged Rollout '''<br>


#'''Information about next release '''should be communicated
#Quality Assurance – through
#*'''during OMB meeting''' (at least one week before release)
#*[[EGI Quality Criteria Definition|Quality Criteria definition ]]– definition and updates of the Quality Criteria used in the Software Verification step
#*'''during URT meeting''' (at least one week before release)
#*Quality Criteria Verification
#**One slide information should be sent to urt-discuss@mailman.egi.eu
#**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
#**TP are informed regarding issues discovered, workarounds needed – through GGUS
#[[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.
#**Reports with the results of this testing phase are recorded in [https://documents.egi.eu/public/ShowDocument?docid=254 DocDB]


=== Deploy Release  ===
<br>


#For '''changes of high impact and high risk''', the steps required to reverse an unsuccessful change or remedy any negative effects shall be defined.
== Support ==
 
=== Review Release  ===
 
#'''Each release should be monitored for success or failure''' and the results shall be analysed internally. <br>
 
== Incident and Problem management ==
 
'''Goal: To restore normal/agreed service operations within the agreed time after the occurrence of an incident, and to investigate the root causes of (recurring) incidents in order to avoid future recurrence of incidents by resolving the underlying problem, or to ensure workarounds are available. '''
 
=== Incident and requests management  ===


Support should be provided:  
Support should be provided:  


*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 ]](default:&nbsp;Medium)&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'''
*'''Support is available'''
**from Monday to Friday
**8 h per day<br>
*All incidents and requests should be'''(assign to proper Support Unit) and [[FAQ GGUS-Ticket-Priority|prioritized]]''' according to suitable scheme.<br>


=== Problems management  ===
<br>
 
#In case of '''recurring incidents '''which cannot be solved by the Provider a GGUS ticket should be created to "Operations" &nbsp;Support Unit. EGI Operations team will coordinate investigation of&nbsp; the root causes of (recurring) incidents in order to avoid future recurrence of incidents.&nbsp;
#*Any existing GGUS tickets which may help investigation should be marked as a child to the created ticket.
 
=== Planned maintenance windows or interruptions  === '''TBD_NOT_CLEAR IF APPLICABLE TO TP/COMPONENTS'''
 
'''Planned maintenance''' should be
 
*declared in GOCDB in a timely manner i.e. '''24 hours before'''
*with typical duration up to 24 hours otherwise needs to be justified
 
'''Unscheduled interruptions '''should be managed according to [[MAN04 Tool Intervention Management|MAN04]]
 
=== Security incidents  ===
 
All security incidents should be registered according to [[EGI CSIRT:Incident reporting|EGI_CSIRT:Incident_reporting]]
 
=== Monitoring  ===
 
Provider is '''responsible''' for development, maintenance and support of the Component '''monitoring probes.'''
 
Availability and reliability threshold should be defined with EGI Operations team depending on criticality of the service.


== Information Security management  ==
== Information Security management  ==


'''Goal: to manage information security effectively through all activities performed to deliver and manage services, so that confidentiality, integrity and accessibility of relevant assets are preserved<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>  


== Customer relationship management'''<br>'''  ==
<br>  
 
'''Goal:''' '''Establish and maintain a good relationship with customers receiving service'''
 
The Provider interacts with EGI.eu, primarily with [[OMB|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 <br>
 
'''Interactions with customers '''are guaranteed through periodic OMB&nbsp;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.<br>  


<br>  
<br>  
Line 222: Line 136:
<br>  
<br>  


<br>
[[Category:Technology]]

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.