UMD Release Process

From EGIWiki
Jump to: navigation, search
Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary


Software Provisioning menu: Home Software Provisioning Process UMD Release Process Quality Assurance UMD Staged Rollout



Contents


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

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:
  • SVG RAT drafts advisory for a vulnerability, and notifies the Technology Provider.
  • Technology Provider confirms product version that fixes the vulnerability (e.g. BDII core 1.2.3), and the planned release (e.g. EMI-1 Update 13) in the vulnerabilities dashboard.
  • UMD release manager cross checks this dashboard with any planned UMD releases.
  • The resulting list is circulated to UMD release documentation team (TSA2.3 and TSA1.3), and the RAT manager
  • UMD releases CSIRT Advisories are published cross-referencing each other
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:
  1. Description
  2. Contact Info
  3. Technical Contact Info
  4. Release Notes
  5. Installation Notes
  6. Known Issues
  7. Change Log

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:
  1. Add the UMD release announcement to UMD release schedule overview
  2. Add text "EGI has released UMD 1.4.0 on 19 December 2011. (Announcement)" linking to the repository's announcement
  3. Remove the entire Release Plan section in the release's Wiki entry
  4. Ensure that the Delivery slip is kept
  5. protect the release wiki entry (hence the delivery slip too) against changes
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:

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export