EGI Software Component Delivery

Main

EGI.eu operations services

Support

Documentation

Tools

Activities

Performance

Technology

Catch-all Services

Resource Allocation

Security

Tools menu:	• Main page	• Instructions for developers	• AAI Proxy	• Accounting Portal	• Accounting Repository	• AppDB	• ARGO	• GGUS	• GOCDB
• Message brokers	• Licenses	• OTAGs	• Operations Portal	• Perun	• EGI Collaboration tools	• LToS	• EGI Workload Manager

Initial activities

Goal: Introducing new Component.
Every new Technological Provider (TP) will join the UMD Release Team (URT).
Every new Component will be introduced in UMD contacting the URT providing following data:

1. Name of the Component
2. Contacts (support email address, web site address)
3. Name and contact details of the Component Development Team Leader
4. Description of the Component/Purpose
5. License
   

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

1. Registration in GOCDB under EGI.eu NGI
2. Create category in "Requirements" queue in EGI RT tracker and RT dashboard to receive and handle service requests
3. Create GGUS Support Unit to receive and handle incidents (define level of quality of support - default: Medium)
4. Negotiate and sign Technical Provider Underpinning Agreement (TP UA) https://documents.egi.eu/document/2282 with EGI.eu
   
5. 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)
       
   • 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

Ongoing activities

Change management

Goal: 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.

Record

1. EGI recording system is EGI RT 
2. EGI user are instructed to submit changes requests in EGI RT.
3. If the Component has other customers than EGI, the Provider will inform EGI about submitted change requests from other customers.
4. The following information will be provided:
   • Product Name and Version
   • What’s New (bug fixes, new features...)
   • Installation & Configuration instructions (what needs to be done to correctly update the Component on the production infrastructure
   • List of Packages to be updated
   • Location where the packages are available (TP repositories, AppDB...)
5. Minimum set of statuses of entry
   • New - newly recorded in system
   • Accepted - accepted by AG/OMB
   • Rejected - rejected by AG/OMB
   • In progress/Open - TP is working on the request
     
   • Resolved - released
   • Stalled - on hold

Classify

1. All change requests should be classified in consistent manner. Classification in EGI RT is based on the Component the request is related to.
   
2. 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.
3. 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

1. Each change request should be commented by the TP with assessment of work needed to implement change.
2. Every change which is not a standard change or emergency change should be assessed (prioritized)and approved internally, in the URT and with OMB.
3. Where needed dedicated 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.
   
4. 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

Phase which take place in Release and deployment management (see below).

Review

1. Every release is subject to post-implementation review. Within one week customers are providing feedback answering to following questions:
   • Were release notes and documentation sufficient?
   • Is the tool working as expected?
     

Release and deployment management

Goal: To bundle changes to release, so that these changes can be tested and deployed to the production environment together.

Plan Release

1. Release schedules should be defined - the frequency of releases (eg. every 1-2 month).
   
2. Scope of every release should be defined.
3. 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

1. Due to the open-source nature of the developed software, each Component should have/use a publicly available code repository, like SVN, CVS, GIT
   • preferred Software Versioning Control system - GITHUB (https://github.com/)
2. 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: FHS, EPEL-GuidelinesAndPolicies, Debian Policies)
3. Distribution
   • • new releases should be distributed as binaries through the UMD repository

Test Release

1. Testing of the software, prior to its release, is a responsibility of the Provider.
2. Where dedicated AG exists it can be involved in the testing activity.
3. Major or particularly important releases should pass acceptance testing performed by customer representatives
4. 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:
   • release notes, containing changelog, installation & configuration steps to apply the update, any known issues
   • documentation links
   • detailed test plan
     
   • all the information needed by the conformance criteria set by the SA2 activity for the software providers.
   • the expected release date and the kind of testing will depend on each specific release and on its importance.
5. 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.

Document

1. The Provider is responsible for creation and maintenance of documentations, instructions and manuals related to the Component in collaboration with EGI Operations team.
2. Before each release documentation should be checked and updated when/where needed.
   

Inform

1. Information about next release should be communicated
   • during OMB meeting (at least one week before release)
   • during URT meeting (at least one week before release)
     • One slide information should be sent to urt-discuss@mailman.egi.eu

Deploy Release

1. For changes of high impact and high risk, the steps required to reverse an unsuccessful change or remedy any negative effects shall be defined.

Review Release

1. Each release should be monitored for success or failure and the results shall be analysed internally.
   

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

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