Skip to content

Release Elements

A release represents a collection of related and unrelated ChangeMan ZMF change packages that must be installed in the same time frame. A release is an enterprise unit of work, just as a change package is a change request unit of work, and a component in a change package is a developer unit of work.

In ERO, a release is a logical set of rules for relating the physical parts of a release, which are areas, applications, library types, and SYSLIB concatenations. These rules and relationships include.

  • Definitions of the areas that make up the release.

  • Rules that set limits on the flexibility of area rules that control functions like area approvals, check-in, retrieve, and blocking.

  • Hierarchy of approvals required before the release can be installed.

  • List of applications and library types that are included in the release.

  • List of prior release containing applications and library types to be used in build processes, release audit, and checkout from release.

Release Application

Applications are joined to a release by an administrator, who also chooses what library types from each application are included in the release. By restricting library types in a release, administrators can build special purpose releases like on-line or batch releases.

Release application definitions also include:

  • A specification of how certain library like-types are ordered in the SYSLIB library concatenations for build processes.

  • Specification of related applications, which are applications that contain components necessary for building other applications.

Release Area

A release area is a set of libraries that represent a step in the consolidation of the components managed by the release. These libraries are used in SYSLIB concatenations for build processes in release packages, and they are used by release audit to validate release component relationships.

Each release must contain at least two release areas.

  • Starting area -The point where components enter the release through release package check-in.

  • Final area - The final stage of consolidation into a single set of library type based libraries. Components are installed into production from final release area libraries.

Release area definitions also include:

  • Audit level for the area, which determines what out-of-sync conditions are allowed in the area, and what conditions trigger stage, recompile, or relink in release audit Auto Resolve.

  • Rules that determine the latitude allowed to developers and release managers as they execute area functions like approvals, check-in, retrieve, and blocking.

  • Rules that may restrict who can execute area functions like check-in, retrieve, and blocking.

  • List of approvers that may be required before components can be checked in to an area or before the release life cycle can proceed to the next area.

Release Package

A planned simple change package becomes a release package when it is attached to a particular release and its starting area is defined. The install date for a release package must fall within the range of the install dates defined for the release. Unplanned, temporary, participating, complex, and super packages cannot be attached to a release.

When a package is attached to a release, ERO takes control of building the SYSLIB concatenations for stage, recompile, and relink jobs. If components in area libraries must be changed, a developer makes the change in package staging libraries using familiar ChangeMan ZMF procedures. The component is then checked in to release again.

Anatomy of a Release

This diagram shows the relationship between a release and its areas, applications, and library types for area libraries.

Release Cycle