UMD Release Process
|Technology||Software Component Delivery||Software Provisioning||UMD Middleware||Cloud Middleware Distribution||Containers Distribution||Technology Glossary|
|Software Provisioning menu:||Software Provisioning Process||UMD Release Process||Quality Assurance||UMD||Staged Rollout|
The UMD Release process collects new software, and updated software, into bundled publications and updates of the UMD.
Mapping EGI Capabilities
Within that process, product updates are mapped to EGI Capabilities that are provided by the various services included in the UMD. In general, the UMD is a service orientated collection of software, therefore EGI Capabilities are mapped against services, instead of libraries.
Technology Providers currently deliver software on all levels, i.e. not only well-defined, packaged and encapsulated services, but also libraries, tools, and APIs or even pure header files. To help maintaining overview on the provided capabilities, EGI maintains a mapping table of UMD capabilities against delivered software.
Ensuring UMD release quality
To ensure that UMD releases consistently deliver the same level of quality, a delivery slip for UMD Releases is maintained.
The following section provides a simple checklist table template. For each UMD release maintained in the Wiki, a copy of this template should be maintained and updated as a delivery slip. This slip documents not only progress in the release activity, but also reminds people of the necessary next steps before a UMD release may be published in the EGI Software Repository.
Starting with the freeze of the UMD release contents (1 week before the planned UMD release date), members of the Technology Unit are working against the checklist, this collaboratively ensuring the quality of the delivered UMD release.
For each UMD release, a separate page in the EGI wiki will be maintained (e.g. UMD 1.4.0). Each UMD release page will provide information about:
- Planned contents (may change until contents freeze)
- UMD Release delivery slip
To start the UMD Release, Provisioning management will simply copy the template into its own section on the release documentation page, for all team members to start working against it.
Ticking off an action
The checklist contains a set of actions that must be carried out. To document that the action is completed, the representative of the responsible unit "ticks" this off by adding her name, and a link to documentation and details of the work done (e.g. a link to the Known issues documentation in the wiki).
Only by adding the name the action is considered complete.
Delivery slip template
|No.||Action||Description||Responsible unit||due on||References|| signed off by
|1||Freeze UMD release contents||Using the UMD Composer add all products that are queued in the UMDStore to a new UMD release bundle.||TSA2.1||Before T - 7||
|2||Update UMD capabilities||Check that UMD Capabilities in UMD-1:Capabilities are up to date and in synch with the products in the UMD release.||TSA2.3, TSA1.3||Before T - 7||
|3||"Known Issues & Installation notes"||Check that sub-actions are finished according to requirements||TSA2.1||T - 4||
|3.1 - Create Wiki entry|| Create a Wiki entry for the release at UMD-x:UMD-x.y.z using the major (x), minor (y) and revision (z) numbers of the UMD release.
Create sections for each product that is included in the documented UMD release.
|TSA2.4||T - 7||
|3.2 - Document Verification findings||Add all findings (bugs, workarounds, etc.) collected in the QC Verification reports to the "Known Issues & Installation notes" wiki entry.||TSA2.3||T - 7||
|3.3 - Document Staged Rollout findings||Collect all issues, warnings, workarounds etc. to the "Known issues & Installation notes" wiki entry.||TSA1.3||T - 7||
|3.4 - Cross-link advisories|| Use the Vulnerabilities Dashboard, and contact Linda Cornwall about any advisories on any pending security vulnerabilities that require cross-linking:
||TSA2.3, TSA1.3||T - 7||
|4||Compile UMD release documentation|| UMD release metadata will be published in the UMD Repository and must cover the following sections:
TSA1.3, TSA2.3 will contribute. TSA1.3 and all SA2 tasks review drafts and give comments.
|TSA2.3||T - 7||
|5||Produce and test release candidate(s)||Produce as many Release Candidates as required based on the feedback given. If no feedback is given assume the Release Candidate working correctly. For each Release Candidate round new sub-actions need to be created for the delivery slip.||TSA2.1||T - 7||
|5.1 - Produce first release candidate||From the list of included products in (1) generate a Release Candidate. Notify TSA2.4 and TSA1.3 of the existence and location of the Release Candidate.||TSA2.4||T - 7||
|5.2 - Test first Release Candidate (Verification)||Test the first release candidate for errors and advise TSA2.4 whether to create another Release Candidate. Testing is mandatory for TSA2.3.||TSA2.3||T - 5||
|5.3 - Test the first Release Candidate (SR)||Call for volunteers for RC testing among the EAs in Staged Rollout. Collect feedback from participating sites and advise TSA2.4 whether to create another Release Candidate. Testing is optional for TSA1.3.||TSA1.3||T - 5||
|6||Publish UMD release||Only when all previous actions are signed off, publish the UMD release.||TSA2.1||T||
|7||Post-release cleanup|| Post-release actions perform some housekeeping in the UMD release management area, including:
UMD Repository layout
EGI follows its own release schedule, publishing fixed UMD updates (monthly/quarterly). Accepted PPA (Product per Platform and Architecture) versions are stored into a staging area of the EGI Repository as delivered by the Technology Providers. When a new UMD release is to be created, the UMD Release building process collects the qualifying and compatible with each other Products from the EGI Repository and bundles them into UMD releases. That is, a UMD release is irrespective of the Technology Providers releases.
There are three types of UMD Releases:
- Base, a new major release
- Update, a subsequent minor release