Structure of a Release

Help Image

The upper section of the Release editor consists of the following tabs:

Master: Contains some general information about the Release.

The key attributes are:

Status
The current status of the Release. When a new Release has been created, it gets the 'Created' status. As soon as you fill in all the required data and click the 'Requested' button, the status changes to 'Requested'. The further status changes will be driven by the Process Engine from now on.
Release Name
The name of the Release.
Release Version
The version of the Release.
Successive Release
A link to the successive Release which replaces the expired Release.
Release-Form
Determines the essential Release classification.

Release Package: A Release Package is the smallest unit of a Release. A small, non-complex Release can be the Release Package only. The Release Package can be created and processed even without Release Units. For each Release Package, a BPMN process instance is created.

Example: A new release for MS Word 2013 is necessary. As this is not a very complex release, only the Release Package is needed.

Release Unit: A Release Unit is a sub-object of the Release Package. A Release Package can have more than 1 Release Units (1:n) assigned. A Release Unit cannot be created and processed without a relation to the Release Package. It is recommended that you use the Units in case the Release is complex and can be divided into several topics.

Example: A new release for USU Valuemation 4.6 is necessary. As this is the more complex case, the following structure is used:
- Release Package: USU Valuemation 4.6
  Release unit 1: USU Valuemation 4.6 Rich Client
  
  Release unit 2: USU Valuemation 4.6 Web Client (the application server)
  
  Release unit 3: USU Valuemation 4.6 Database
If a Release Package is assigned to one or more Units, the process instance of the Package is stopped and we have one independent process instance for each unit.
Release Type
- Emergency Release
  The emergency releases are modifications repairing a error quickly. For example, the version 1.1.1, 1.1.2 etc.
- Major Release
  A release which represents a significant roll-out of hardware and software and which introduces important modifications to the functionality or technical characteristics. For example, the version 1.0, 2.0, etc.
- Minor Release
  The minor releases usually entail a correction of one or more specific errors and are often modifications that implement the documented emergency solutions correctly. For example, the version 1.1, 1.2, 1.3, etc.
Release Category
- Full Release
  All the affected components are distributed, whether they have been modified or not. Although this option obviously involves more work, it is less likely that incidents will occur after the installation (provided the relevant tests have been done).
- Delta Release
  Only the modified components are tested and installed. This option has the advantage of greatest simplicity but it entails risk that problems or incompatibilities may arise in the live environment.
Impact, Urgency
The Impact/Urgency describes the urgency of a Release.
Priority
The Priority reflects the importance of a solution. Assigning a Priority to a Release is the result of Business Rules.

Deadlines: This tab is concerned with the dates and times involved in the Release.

Risk Rating: Risk rating of a Release is handled by a special risk rating object linked to the Release. The object contains information relevant for a risk assessment of the Release. This information is displayed on the Risk Rating tab of the Release editor.

Risk Rating can be created and updated when a Release is in the 'In Planning' status.

Details: Contains the creation date, the date of the last change and the corresponding information on the responsible user.