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.
UMD Release Process
| Technology | Software Component Delivery | Software Provisioning | UMD Middleware | Cloud Middleware Distribution | Containers Distribution | Technology Glossary |
| UMD Provisioning | | Software Provisioning Process | | UMD Release Process | | Software Provisioning Release descriptor tool | | Glossary |
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.
Checklist HOWTO
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 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.
Checklist template
| No# | Action | Description | Responsible unit | Time Constraint | Status |
| 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 -1 Week | |
| 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. | TSA1.3, TSA2.2, TSA2.3 | Before T -1 Week | |
| 3 | Compile a "Known issues" | In the Wiki, compile a "Known issues" page for the pertinent UMD release at UMD-x:UMD-x.y.z using the major (x), minor (y) and revision(z) numbers of the UMD release. The page must contain one entry per Product contained in the UMD release. |
TSA1.3, TSA2.2, TSA2.3 | Before T -1 Week | |
| 4 | Compile UMD release metadata | UMD release metadata will be published in the UMD Repository and must cover the following sections:
|
TSA1.3, TSA2.2, TSA2.3 | During T -1 Week | |
| 5 | Release Candidate(s) | Produce release candidates as required based on feedback from EA.
|
TSA2.4 | ON T -1 Week | |
| 6 | Manage RC testing with StagedRollout EAs | Announce RC availability to EAs and document collected feedback, and inform TSA2.4 about the outcome. | TSA1.3 | During T -1 Week | |
| 7 | Repeat (5) and (6) as required | For as long as there is feedback that stops publishing the UMD release, correct the reported issues and re-issue a new Release Candidate | TSA1.3, TSA2.4 | During T -1 Week | |
| 8 | Final UMD release publication | Check the release matadata, the capabilities, and release contents before doing the release | TSA2.1 | on T | |
| 9 | Release post-processing | Update release plans in the Wiki, replacing the release contents plan with a link to the announcement. Set the announcement link in the Release Schedule overview, too. | TSA2.1 | After T |
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