Difference between revisions of "EGI Software Component Delivery"
Line 77: | Line 77: | ||
#Quality Assurance – through | #Quality Assurance – through | ||
#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 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 | #**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 ]] | ||
#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 DocDB | #**Reports with the results of this testing phase are recorded in [https://documents.egi.eu/public/ShowDocument?docid=254 DocDB] | ||
<br> | <br> | ||
Line 94: | Line 94: | ||
<br> | <br> | ||
<br> | <br> | ||
== Incident and Problem management == | == Incident and Problem management == |
Revision as of 11:19, 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:
- 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
Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:
- Software Delivery – Technology Providers submit new software releases
- Software Assessment – through Quality Assurance & Staged Rollout
- Reporting – inform TP about outcome of the software provisioning process
Small workflow diagram representing status of products through the Software Provisioning Process:
Initial activities - Joining UMD Release Team
To become included in UMD Release Team (URT) Technology provider should provide following information:
- Name of the Product team
- Contacts (support email address, web site address)
- Name and contact details of the Component Development Team Leader
- Description of the Component/Purpose
Please read: How to join
With the help of the EGI UMD Release Team (URT), the following steps need to be performed:
- Create GGUS Support Unit to receive and handle incidents (define level of quality of support)
- Agree on Technical Provider Underpinning Agreement (TP UA) with EGI.eu
- Subscribe to the UMD Release team mailing list
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
- Communicate information about new update
- E-mail to URT team
- Update the information on the URT meeting agendas
- 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
- AppDb
Software Assessment
Goal: Assessment through Quality Assurance & Staged Rollout
- 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
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:
- 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 (default: Medium)
- Support is provided in English
- Support is available
- from Monday to Friday
- 8 h per day
- All incidents and requests should be(assign to proper Support Unit) and prioritized according to suitable scheme.
Problems management
- In case of recurring incidents which cannot be solved by the Provider a GGUS ticket should be created to "Operations" Support Unit. EGI Operations team will coordinate investigation of the root causes of (recurring) incidents in order to avoid future recurrence of incidents.
- 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
Security incidents
All security incidents should be registered according to 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
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
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.