Skip to content

The Role of Release Manager

ERO introduces the role of a Release Manager. This role creates and manages releases and their associated areas. The responsibilities of a release manager include:

Creating Releases

You create releases with a unique 1-8 character release identifier. The release identifier is used as a node in the dataset names for release area libraries. Information required includes:

  • Release Description

  • Audit Level

  • The minimum rules that may be used for areas in the release. The least restrictive rules can be set for Approvals, Blocking, Check-in, and Retrieve.

  • Ascending or Descending SYSLIB Order of Area libraries

    Ascending order is forward from the current area libraries to the final area libraries. Ascending order ensures you that the latest changes checked into areas starting from the target area to the final area are used instead of earlier changes that are resident in the final area.

    Descending order is backward from the final area libraries to the current area libraries. Descending order ensures you that the earliest changes checked into areas starting from the final area to the target area are used instead of later changes.

  • Auto Clean-up of Release Packages When you test the content of the final release area against the content of the release packages, components in the staging libraries that have not made it into the final area can automatically be deleted.

  • Install Date and Time Range

  • Installation/Problem Handling Instructions

  • Release Order

The following panel shows the first part of release parameters you enter when you define a release. The input fields include, among others, Release Description, Minimum rule levels, and SYSLIB Concatenation Order.

CMNRMRC0 FIN6460 Release Management Parameters - Part 1 of 2
Command ===>

Release description . . . . . FIN6450 Release for test
Creator . . . . . . . . . . . USER123
Creator's Phone Number . . . 11292
Work request . . . . . . . . WR 9015
Department . . . . . . . . . FINANCE
Minimum audit level . . . . . 0   (0,1,2,3,4,5)
Minimum approval rule . . . . 0   (0,1,2,3)
Minimum blocking rule . . . . 0   (0,1,2,3,4,5,6,7)
Minimum Check-in rule . . . . 0   (0,1,2,3,4,5,6,7)
Minimum retrieve rule . . . . 0   (0,1,2,3)
SYSLIB concatenation order .  A   (A-Ascending,D-Descending)
Default IHA audit setting . . N   (Y/N/C)
Enter "/" to select option
  __ / Enforce IHA default setting
  __ Bypass checkin package requirements
  __ Allow empty packages to process in release
  __ Auto cleanup of packages in DEV status
  __ Auto cleanup of packages in FRZ status
  __ Auto cleanup of packages in APR status

Defining Install Approvers for a Release

You can select which approvers are needed for a particular release from the list of approvers defined at a global level.

Defining Areas to a Release

You create areas with a unique 1-8 character area name, which is used in the dataset name for release area libraries. At least one start (subsystem area) and one final (system area) must be defined in a release.

Required information includes:

  • Area Description

  • Audit level

  • Any Prior Area Name

  • The Next Area Name

  • The minimum rules that may be used for areas in the release. The least restrictive rules can be set for Approvals, Blocking, Check-in, and Retrieve. These Area Functions’ Rules can be more restrictive than the Release minimum rules.

The following panel shows the above parameters as input fields when creating an area.

CMNRMAC0 FIN6410 R041218 Area Parameters - Part 1 of 2
Command ===>

Area description . . Final area for Finance components
Area step number . . . . . . . . . . 0003
Area step type . . . . . . . . . . . 1   (Subsystem-0 or System-1)
Any prior area name . . . . . . . . GENLEDGR
The next area name . . . . . . . . .
Area audit level . . . . . . . . . . 0   (0,1,2,3,4,5)
Area approval rule . . . . . . . . . 0   (0,1,2,3)
Area blocking rule . . . . . . . . . 0   (0,1,2,3,4,5,6,7)
Blocking entity . . . . . . . . . .      (Entity Name)
Area check-in rule . . . . . . . . . 0   (0,1,2,3,4,5,6,7)
Check-in Entity . . . . . . . . . .      (Entity Name)
Area retrieve rule . . . . . . . . . 0   (0,1,2,3)
Retrieve entity . . . . . . . . . .      (Entity Name)
Enter "/" to select option
  __ / Allow component checkout
  __ / Add associated approvers
  __ Exclude area from SYSLIB
  __ Override overlaid components

CMNRMAC1 FIN6410 R041218 Area Parameters - Part 2 of 2
Command ===>

Enter "/" to select option
  __ Exclude packages in DEV status
  __ Exclude packages in FRZ status
  __ Exclude packages in APR status
  __ Exclude empty packages
  __ Exclude package integrity check

Adding Check-In and Check-Off Area Approvers

You can add area check-in and check-off area approvers, which are selected from the Global Approval List. If specified, check-in approval is required before check-in to the area is permitted. Check-off approval is required before migration from this area.

The following panels show part 1 and 2 for defining area approvers. Input fields are Approver Order Number, Check-in Approver, Check-off Approver, and Description.

CMNRMAA0 Approver Parameters - Part 1 of 2
Command ===>

Release: FIN6410    Area: ACCTPAY   Entity: ACTPLEAD
Description . . . . . . . . Lead Developer ACTP Application
Order Number . . . . . . .  0010
Enter "/" to select option
  __ Check-in Approver
  /  Check-off Approver
Approver List Count . . . . 0001

CMNRMAA1 Approver Parameters - Part 2 of 2 Row 1 to 1 of 1
Command ===> Scroll ===> CSR

Release: FIN6410    Area: ACCTPAY   Entity: ACTPLEAD
Approver: Lead Developer ACTP Application
Order no: 0010
Vehicle User(s) to notify
MVSSEND jsmith

Blocking a Release

When you block a release, it locks down the release and its areas in preparation for install.

The following panel lists releases, and indicates the line command BK is used to block a release. Other available line commands include AR, which is used to approve a release, and BR, which is used to view backout reasons.

CMNRMRLF Release List Row 1 to 2 of 2
Command ===> Scroll ===> CSR

Release Sta Install   Work request  Dept    Aud Creator Pkgs
FIN6410 DEV 20160428  WR 9010       FINANCE     JSMITH  00002
FIN6430 DEV 20160428  WR 9030       FINANCE     JSMITH  00002

Approving a Release

After a release is blocked, all install approvers must enter their approvals before the release will install. If a release is unblocked, all approvals entered up to that point are cleared, and they must be entered again after the release is blocked. If an approver rejects the release, the release must be reverted to clear the rejection, and all install approvals must be entered again.

Installing a Release

Packages attached to a release are distributed when all release approvals are entered and the release status is changed to approved (APR). Each package attached to a release is installed according to the package Scheduler and Install Date/Time. When a package attached to a release is installed successfully, the package status in the development instance is changed to baseline (BAS).

Although release components are installed on a package-by-package basis, the components are copied from final release area libraries rather than from package staging libraries.

Backing Out a Release

Release backout submits backout jobs for all packages attached to the release. After completion, the release status is changed to BAK. To return the release to DEV status, you would revert the release.

Unblocking a Release

Unblocking a release unlocks the release for further changes. Unblocking a release does not unblock the areas in the release. You must unblock release areas to change release components.

If a release is unblocked, all approvals entered up to that point are cleared, and they must be entered again after the release is blocked.

Unblocking an Area

Release managers can block area libraries to disallow component migration into predefined release areas. They unblock areas libraries to allow component migration to begin.

More information