|
Term |
Definition |
| RFC (Request for Change) | A high-level change request that captures the detail of a change that is to be made to a new or existing application. RFCs are usually decomposed down to lower level work requests or tasks for software development. |
| CAB (Change Advisory Board) | The collection of stakeholders who review all RFCs at specific intervals to assess whether they should be implemented, assign priorities and allocated them to a Release. |
| Release | A stable, executable version of a product intended for deployment to testing and production. |
| Release Package | A logical container that defines the set of RFCs and Deployment Units (sometimes called Release Units) that are to be included in a Release. It also includes metadata such as the type of release (see Release Type) and its planned dates (see Release Calendar). |
| Release Type | The type of release that is to be implemented, i.e. Major, Minor, Emergency. Each Release Type will usually have a different workflow. |
| Release Policy | An organisations published policy that determines under which circumstances different Release Types should be used as well as the standard set of milestones that selecting a particular Release Type implies in the Release Calendar. |
| Release Calendar | A set of published milestones that details when Releases are planned to transition through the different development, test and production phases. |
| Baseline | A snapshot of the exact versions of Configuration Items, including executables, libraries, configuration files and documentation that are to be deployed. |
| Build | An operational version of a product or part of a product. Not all builds are released but builds are typically carried to transform inputs (source code) into executed and installable Deployment Units. |
| Deployment Unit | A physical, self-contained, installable release of an application. |
#IBMi Software Release Management
March 27, 2012