Difference between revisions of "EGI Software Component Delivery"
Line 3: | Line 3: | ||
= EGI Software Component Delivery = | = EGI Software Component Delivery = | ||
==Component roadmap and release plan== | == Component roadmap and release plan == | ||
The Provider will publish a roadmap | 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: | ||
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 major component releases | ||
* All planned minor component releases | *All planned minor component releases | ||
* Planned new features in the component | *Planned new features in the component | ||
* Incompatibilities between releases | *Incompatibilities between releases | ||
<br> | <br> | ||
The Provider will update the | 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]. | ||
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 | The Provider will make available a 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 | ||
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 | *All major releases | ||
* All minor releases | *All minor releases | ||
Technology Provider agrees to inform EGI whenever the release plan is changed. | Technology Provider agrees to inform EGI whenever the release plan is changed. | ||
<br> | <br> | ||
Release delivery and format | Release delivery and format | ||
The Provider agrees to deliver | The Provider agrees to deliver 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> | ||
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 == | == Quality Assurance == | ||
The Provider understands and | 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. | ||
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=== | === Acceptance Criteria === | ||
The evolution of acceptance | The evolution of acceptance criteria is a normal process considering the settings within which EGI and the Provider operate. <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. | ||
criteria is a normal process considering the settings within which | |||
EGI and the Provider operate. | |||
<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 | === Test plans === | ||
The Provider agrees to formally | 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. | ||
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 | The test plan for a given release of one particular component must include: | ||
of one particular component must include: | |||
* All tests available, or at least an executive overview of all tests available | *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 list of all tests executed for the given release of given component | ||
* The complete, detailed result of each executed test | *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. | *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 | The test plan as described above must be made available to EGI prior to the planned release date for review: | ||
review: | |||
* Major release: At least 20 working days | *Major release: At least 20 working days | ||
* Minor release: At least 15 working days | *Minor release: At least 15 working days | ||
* Revision release: At least 10 working days | *Revision release: At least 10 working days | ||
* Emergency release: N/A | *Emergency release: N/A | ||
<br> | <br> | ||
Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania] | Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania] and upon request of EGI’s appropriate management unit, the Provider, in collaboration with EGI, agrees to the best of their ability to: | ||
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== | == Issue management == | ||
The Provider has appointed personnel for technical issues concerning the maintained software | 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> | ||
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> | |||
===Issue management infrastructure=== | === Issue management infrastructure === | ||
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 | 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 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. | ||
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. | |||
<br> | <br> | ||
Line 122: | Line 80: | ||
=== Issue Resolution === | === Issue Resolution === | ||
The Provider constructively works in close collaboration with EGI DMSU on jointly investigating issues | 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]. | ||
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> | <br> | ||
In case the triage resolves to the | In case the triage resolves to the production of a new release of the affected software component DMSU and the service provider jointly agree on an Estimated Time of Availability (ETA) of the necessary new release of that software component.<br> | ||
production of a new release of the affected software component DMSU | |||
and the service provider jointly agree on an Estimated Time of | |||
Availability (ETA) of the necessary new release of that software | |||
component.<br> | |||
The Provider agrees to prioritise | The Provider agrees to prioritise 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: | ||
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> | #Top priority<br> | ||
#Very urgent<br> | #Very urgent<br> | ||
#Urgent<br> | #Urgent<br> | ||
#Less Urgent<br> | #Less Urgent<br> | ||
==Vulnerability management== | == Vulnerability management == | ||
The Provider has appointed | The Provider has appointed 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. | ||
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> | <br> | ||
Any appointed security contact for | 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. | ||
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=== | === Vulnerability Resolution === | ||
The Provider agrees that any | The Provider agrees that any software vulnerability found in their delivered software while running on EGI production infrastructure must be handled using the SVG process [Błąd: Nie znaleziono źródła odwołania]. | ||
software vulnerability found in their delivered software while | |||
running on EGI production infrastructure must be handled using the | |||
SVG process [Błąd: Nie znaleziono źródła odwołania]. | |||
<br> | <br> | ||
The Provider agrees that any | The Provider agrees that any 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. | ||
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> | <br> | ||
The Provider agrees to prioritise | The Provider agrees to prioritise vulnerability resolution according to their risk assessment, in the following order: | ||
vulnerability resolution according to their risk assessment, in the | |||
following order: | |||
#Critical | #Critical | ||
#High | #High | ||
#Moderate | #Moderate | ||
#Low | #Low | ||
<br> | <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. | 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 == | == Metrics == | ||
Line 241: | Line 166: | ||
<br> | |||
<br> | <br> | ||
Line 260: | Line 187: | ||
<br> | |||
<br> | <br> | ||
Line 345: | Line 274: | ||
<br> | |||
<br> | <br> | ||
Line 364: | Line 295: | ||
<br> | |||
<br> | <br> | ||
Line 384: | Line 317: | ||
<br> | |||
<br> | <br> | ||
Line 437: | Line 372: | ||
<br> | |||
<br> | <br> | ||
Line 612: | Line 549: | ||
|} | |} | ||
<br> <br><br> | |||
<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: | 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: |
Revision as of 13:43, 17 February 2015
DRAFT
EGI Software Component Delivery
Component roadmap and release plan
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
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].
The Provider will make available a 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
- All minor releases
Technology Provider agrees to inform EGI whenever the release plan is changed.
Release delivery and format
The Provider agrees to deliver 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].
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.
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
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 3rd party software necessary to execute the test plans.
The test plan as described above must be made available to EGI prior to the planned release date for review:
- Major release: At least 20 working days
- Minor release: At least 15 working days
- Revision release: At least 10 working days
- Emergency release: N/A
Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania] 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
Issue management
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.
Issue management infrastructure
EGI uses GGUS for 2nd level (DMSU) support. For 3rd-level support, EGI provides the Technology Provider with a provider-specific Support Unit (SU) in GGUS as 3rd level support interface. Monitoring and reporting of provider performance is implemented through this SU.
Issue Resolution
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].
In case the triage resolves to the production of a new release of the affected software component DMSU and the service provider jointly agree on an Estimated Time of Availability (ETA) of the necessary new release of that software component.
The Provider agrees to prioritise 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
- Very urgent
- Urgent
- Less Urgent
Vulnerability management
The Provider has appointed 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.
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.
Vulnerability Resolution
The Provider agrees that any software vulnerability found in their delivered software while running on EGI production infrastructure must be handled using the SVG process [Błąd: Nie znaleziono źródła odwołania].
The Provider agrees that any 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.
The Provider agrees to prioritise vulnerability resolution according to their risk assessment, in the following order:
- Critical
- High
- Moderate
- Low
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.
Metrics
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).
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.
|
|
|
|
|
|
|
|
have passed the SW Rollout process are counted.
|
|
|
TD and have passed the SW Rollout process are counted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
have passed the SW Rollout process are counted.
|
|
|
calendar week and have passed the SW Rollout process are counted.
|
|
|
calendar month) and have passed the SW Rollout process are counted.
|
|
|
|
|
|
|
|
|
|
|
|
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.
|
|
|
|
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.