Packages

The following best practices apply to packages:

Set naming standards and use the target stage as the name prefix, if the package is not a promotion package.
Business Value:

Lists of package names are automatically sorted by target stage, which makes it easier to find a specific package.
Use promotion packages for packages that contain Move actions only. The Promotion Package feature lets you use the same package for as many iterations and movements as needed, rather than requiring that you create new packages. If a package is not set up as a promotion package, every time it moves from one stage in the lifecycle to the next, an entirely new package must be created.
Business Value:

If you use a package for move processing only and you need to promote the package all the way through to production, the Promotion Package feature simplifies this process.

Promotion packages provide for greater project control and simplify the movement of packages through the lifecycle. This feature helps you meet regulatory requirements, because it makes it easy to track the transitions in the development of your applications. Promotion packages provide auditors with a complete trail of who did what, when, and where for each iteration of the package. In addition to facilitating project control, promotion packages also make it easier to comply with a standard package naming convention.

Additional Considerations:

Promotion packages can contain Move actions only; no other CA Endevor SCM actions are allowed. Promotion packages keep the same package ID for the entire migration cycle.
Enable the C1DEFLTS STOP@STG feature for promotion packages that require package ship support at a stage prior to the last stage of your software life cycle.
Business Value:

This best practice lets you use promotion packages, but enables you to stop them at one or more designated stages for shipment, prior to completing the promotion to the end of the lifecycle map.
Use external security groups (external security profiles) for approver groups.
Business Value:

This best practice puts the responsibility for maintaining security in the security department, rather than with the change management administrators. This allows for more flexibility in maintaining approver groups by allowing more than 16 approver IDs and the addition or deletion of approvers as needed for a specific package.
Make packages sharable by default.
Business Value:

A sharable package can be maintained by more than one person. If the creator of a package is unavailable when action needs to be taken with that package, having it sharable means that someone else can step in and maintain the package.
Clean up backout members at specific intervals using the COMMIT action.
Business Value:

Backout enabled packages leave encrypted members in the output libraries. The COMMIT action removes those members, thus keeping the library clean and minimizing the space requirements.
Archive after n days.
Business Value:

The Package Master file is a VSAM file which can grow quite large if not maintained. Archiving completed packages that have been committed helps to minimize that growth.
Delete after n days.
Business Value:

The Package Master file is a VSAM file that can grow quite large if not maintained. Deleting unused packages (those that have not been accessed in a set number of days and which are still in the “Being Created” state) will help to minimize the growth of the VSAM file.

Note: For more information about archiving completed packages and deleting unused packages, see the following technical document on http://ca.com/support: TEC348243 When was the last time your site did package clean-up? Does you site have packages that are no longer needed? Read this article to find out how ...