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
 
(62 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<br> <br> DRAFT<br>
{{Tech menubar}}
{{TOC_right}}


= EGI Software Component Delivery  =
<br> EGI's UMD Provisioning activity governs and executes two main processes:


==Component roadmap and release plan==
#'''[[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
The Provider will publish a roadmap
for each component it wishes to release to EGI. The roadmap may be
consolidated into one document with the roadmaps for other components
if the Provider releases more than one component to EGI. The roadmap
must contain:
 
* All planned major component releases
* All planned minor component releases
* Planned new features in the component
* Incompatibilities between releases
 
<br>
 
The Provider will update the
roadmap(s) every half year (six calendar months) at least one
calendar month before EGI publishes the UMD Roadmap on its scheduled
dates [Błąd: Nie znaleziono źródła odwołania].


<br>  
<br>  


The Provider will make available a
Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:
release plan for each component published in the Provider’s
software repository. The Provider may consolidate release plans of
more than one component into a consolidated series of one or more
documents, for a better overview. The release plan must provide the
planned release dates for all maintained software components for at
least one year into the future and must include the release dates for


* All major releases
#'''Software Delivery''' – Technology Providers submit new software releases<br>
* All minor releases
#'''Software Assessment''' – through Quality Assurance &amp; Staged Rollout
 
#'''Reporting '''– inform TP about outcome of the software provisioning process
Technology Provider agrees to inform EGI whenever the release plan is changed.


<br>  
<br>  


Release delivery and format
Small workflow diagram representing status of products through the Software Provisioning Process:


The Provider agrees to deliver
[[Image:Software Provisioning Process.png|300px|Software Provisioning Process.png]]  
releases on a regular basis and provides electronic access to the
release contents as described in [Błąd: Nie znaleziono źródła odwołania].
The new release must be delivered by creating a tracker artefact in
GGUS containing XML based technical description of the release [Błąd: Nie znaleziono źródła odwołania].
<br>


== Quality Assurance  ==
The Provider understands and
accepts the Software Provisioning Process as described in EGI-InSPIRE
Milestone MS503 [Błąd: Nie znaleziono źródła odwołania] and its
designated successors.
=== Acceptance Criteria===
The evolution of acceptance
criteria is a normal process considering the settings within which
EGI and the Provider operate.
<br>  
<br>  
Through active participation in the
TCB the Provider advises EGI on the effort required to implement any
changes to generic or specific acceptance criteria that may affect
any of the maintained software components that are part of, or
considered to be part of, the UMD.
=== Test plans</span>  ===
The Provider agrees to formally
provide or make available to EGI the complete test plans and results
of continuous testing and integration of each maintained software
component.
The test plan for a given release
of one particular component must include:
* All tests available, or at least an executive overview of all tests available
* The complete, detailed list of all tests executed for the given release of given component
* The complete, detailed result of each executed test
* References to and descriptions of any required 3<sup>rd</sup> party software necessary to execute the test plans.


<br>  
<br>  


The test plan as described above must be made available to EGI prior to the planned release date for
= Initial activities - Joining UMD Release Team<br>  =
review:


* Major release: At least 20 working days
To be included in [https://wiki.egi.eu/wiki/URT UMD Release Team (URT)] the interested Technology Provider should provide following information:<br>
* Minor release: At least 15 working days
* Revision release: At least 10 working days
* Emergency release: N/A


<br>  
#'''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/Product and its Purpose<br>  
#'''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 &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 or referenced as being provided by other Technology Providers part of the URT team
#'''Documentation '''references – installation &amp; configuration guides, release notes, known issues and troubleshooting, reference cards
#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.


Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania]
All information will be included into [[UMD_products_ID_cards|UMD products ID card]]  
and upon request of EGI’s appropriate management unit, the Provider, in collaboration with EGI, agrees to the best of their
ability to:


* Rerun the complete test plan for major releases
* Run a subset of the tests of the test plan (chosen by EGI) for minor releases
<br>  
<br>  


==Issue management==
To send join request please read: [[UMD Release Team#How_to_join_URT|'''How to join''']]


The Provider has appointed personnel for technical issues concerning the maintained software
components. Those technical contacts must be fully authorised to act
as the Provider’s representative in collaboration with EGI DMSU [Błąd: Nie znaleziono źródła odwołania]
regarding the triaging, assessment and resolution of any technical
issues concerning the software components developed and maintained by
the Provider.
<br>  
<br>  


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


EGI uses GGUS for 2<sup>nd</sup> level (DMSU) support. For 3<sup>rd</sup>-level support, EGI provides the Technology Provider with a
#Create GGUS Support Unit to receive and handle incidents (define [[FAQ GGUS-QoS-Levels|level of quality of support]])  
provider-specific Support Unit (SU) in GGUS as 3<sup>rd</sup> level support interface. Monitoring and reporting of provider performance is implemented through this SU.
#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


<br>  
<br>  


=== Issue Resolution ===
== First release<br> ==
 
The Provider constructively works in close collaboration with EGI DMSU on jointly investigating issues
raised against software components maintained by the Provider. The
investigation includes triaging the issue or incident, the problem
and any known impacts. The details of the process of collaboration
with the DMSU are outlined in [Błąd: Nie znaleziono źródła odwołania].


<br>
This section describe workflow of adding first release:&nbsp;


In case the triage resolves to the
#First packages are pulled into the '''untested area''' of the UMD repositories
production of a new release of the affected software component DMSU
#UMD team starts the first '''verification''', involving the TP, in order to:
and the service provider jointly agree on an Estimated Time of
#*understand how deployment should be done
Availability (ETA) of the necessary new release of that software
#*check the present Quality Criteria definitions and determine if the common criteria apply or not, if specific criteria are needed for the new products
component.<br>
#*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.


The Provider agrees to prioritise
<br> <br>
the effort to resolve and fix reported issues according to their
priority as set in GGUS, in the following order, while respecting the
constraint of the agreed ETA:


#Top priority<br>
= Ongoing activities<br> =
#Very urgent<br>
#Urgent<br>
#Less Urgent<br>


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


The Provider has appointed
=== Software Delivery<br>  ===
personnel for vulnerability issues concerning the maintained software
components. Those security contacts must be fully authorised to act
as the Provider’s representative in collaboration with EGI SVG [Błąd: Nie znaleziono źródła odwołania]
and related boards regarding the triaging, assessment and resolution
of any vulnerability issues concerning the software components
developed and maintained by the Provider.


<br>
'''Goal: Submitting new software releases'''
 
Any appointed security contact for
any delivered software component must respond to any request by the
EGI SVG and associated groups (e.g. RAT). The response must be as
soon as possible, or at least within 2 working days.


<br>  
<br>  


===Vulnerability Resolution===
#Communicate information about new update
 
#*Send e-mail to URT team
The Provider agrees that any
#*Update the information on the [[URT meetings agendas|URT meeting agendas]]
software vulnerability found in their delivered software while
#Information needed for each update:
running on EGI production infrastructure must be handled using the
#*Product Name &amp; Version
SVG process [Błąd: Nie znaleziono źródła odwołania].
#*Release Notes as:
#**What’s New – bug fixes, new features
#**Installation &amp; 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
#***[https://appdb.egi.eu/browse/software AppDB]


<br>
<br>


The Provider agrees that any
== '''Software Assessment'''  ==
software vulnerability in their delivered software found otherwise
must be reported to the EGI SVG. If the vulnerability is reported
before a fix is available, the vulnerability must be treated and
resolved as if found on EGI production infrastructure, i.e. it must
be handled using the SVG process. If the vulnerability is reported
after a fix is available, the Provider coordinates with SVG to make
available the new release including an appropriate advisory for SW
release on EGI production infrastructure.


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


The Provider agrees to prioritise
#Quality Assurance – through
vulnerability resolution according to their risk assessment, in the
#*[[EGI Quality Criteria Definition|Quality Criteria definition ]]– definition and updates of the Quality Criteria used in the Software Verification step
following order:
#*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
#Critical
#**A [https://documents.egi.eu/document/417 Verification Report] is provided (in DocDB) for the Staged Rollout site
#High
#**TP are informed regarding issues discovered, workarounds needed – through GGUS
#Moderate
#[[Staged-Rollout|Staged Rollout ]]
#Low
#**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]
<br>
 
For any vulnerability found in any software component delivered by the Provider, the Provider agrees to the best of their ability that no information about the vulnerability shall be disclosed to the public without consent of the SVG. Other Software Vulnerability groups may be informed without prior consent of the EGI SVG, provided they have a non-disclosure policy, which is compatible with that of the EGI SVG. Also, IGE and any other vulnerability groups informed must ensure that a fix is available in the UMD prior to public or other widespread disclosure of the vulnerability.


<br>
<br>


== Metrics ==
== Support ==


Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).
Support should be provided:


All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.  
*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;
*Support is provided in '''English'''


{| width="635" cellspacing="0" cellpadding="7"
<br>
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Metric ID'''
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Metric'''
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#'''Explanation'''
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.1
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of confirmed new vulnerabilities per month
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of vulnerabilities discovered in all maintained software components, whether within EGI activities or outside, are collected and published.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.2
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within TD
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within TD </span><span lang="en-US">''and''</span><span lang="en-US">
</span>
 
 
 
<br>  
 
have passed the SW Rollout process are counted.
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.3
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered after TD


| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
== Information Security management  ==
#<span lang="en-US">All fixes that are delivered </span><span lang="en-US">''after''</span><span lang="en-US">
</span>




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>


<br>  
<br>  
TD <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted. </span>
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.4
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of confirmed open vulnerabilities which have exceeded the TD
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Number of confirmed vulnerabilities, which have not been fixed and have passed the TD at the time of calculating.
#Current value taken at the end of the reporting month on the last working at 18:00 CE(S)T.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.5
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Total number of open vulnerabilities
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Current value taken at the end of the reporting month on the last working day at 18:00 CE(S)T.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.6
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of requests to the Provider
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of requests for information and/or participation in investigation of issues to IGE concerning vulnerabilities.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.7
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of contact responses below 2 day target
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Each request made by the SVG or associated boards that were not reacted upon within 2 working days are counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.1
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of issues assigned to the Provider
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total numbers of confirmed issues that require the Provider’s effort to produce a new release are counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.2
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of issues with revised ETA
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of issues for which the Provider changed the ETA are counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.3
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA </span><span lang="en-US">''and''</span><span lang="en-US">
</span>
<br>
have passed the SW Rollout process are counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.4
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA + 1 week
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA + 1
</span>


<br>  
<br>  
calendar week <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted.</span>
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.5
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA + 1 month
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA (+ 1
</span>
<br>
calendar month) <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted.</span>
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.1
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases delivered to EGI
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of releases made available to EGI through the SW Rollout process is counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.2
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that passed the quality criteria verification.
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#All releases that passed the quality criteria verification process are counted. Release submissions that result in changes of quality criteria applicable to the pertinent component are not counted in this metric.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.3
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that passed StageRollout verification
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#All releases that passed the StageRollout phase of the SW rollout process hence are accepted for production use, are counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.1
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of violations of service request response times
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">Every occurrence of a violation of the service
</span>
<br>
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.
#Aggregated during the reporting month.
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.2
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that failed any mandatory Generic Documentation Quality Criterion
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Documentation quality is a critical software quality criterion, but not part of the decision to accept or reject software based on technical failures.
#Aggregated during the reporting month.<br>
|}
<br><br>
== Objectives  ==
Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”
Objectives are calculated using monthly metering of the metrics defined in section .
{| width="635" cellspacing="0" cellpadding="7"
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Objective ID'''
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Objective '''
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Calculation'''
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#'''Target'''
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.1
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Proportion of issues fixed within TD
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#100 * M.SVG.2 /
#(M.SVG.2 + M.SVG.3 + M.SVG.4)
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.2
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Proportion of open issues beyond TD
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.4 / M.SVG.5 * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.3
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Responsiveness of security contacts to vulnerability issues
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.SVG.7 / M.SVG.6) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.1
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.3 / M.DMSU.1) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.2
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA + 1 week
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.4 / M.DMSU.1) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.3
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA + 1 month
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.5 / M.DMSU.1) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.REPO.1
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Formal quality of component releases
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.REPO.2 / M.REPO.1) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.REPO.2
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Functional quality of component releases
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.REPO.3 / M.REPO.1) * 100
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.MISC.1
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Service response time violation
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.1
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#0
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.MISC.2
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Documentation quality failure
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.2
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#0
|}
<br><br>
Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.The performance of IGE in said activities will be individually reviewed and assessed on the following scale:
*Performance above expectations
*Performance as expected
*Performance below expectation
The review will include assessment of the past period, and expectations for the subsequent period.


<br>  
<br>  


[[Category:Infrastructure_Oversight]]
[[Category:Technology]]

Latest revision as of 11: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.