Release packages are portions of IT or Service Infrastructure normally built, deployed, tested, and released together. Release packages define the set of changes to be deployed and drive the deployment processes.
One or more development change requests and deployment units are associated with each release package. Deployment tasks are associated with release packages and are executed as part of the release package workflow.
Release packages can be dependent or independent. Dependent release packages are associated with application releases and are part of the release train hierarchy. Independent release packages are standalone objects.
Dependent release packages are associated with application releases. This ensures that the changes included and deployed as part of the release packages have followed the full workflow and approvals needed for the release train and application release of which they are a part.
Using dependent release packages ensures that complete release scheduling and planning processes are followed before deployment to any environments.
Independent release packages enable you to perform hotfix and emergency releases outside of the scope of a release train and application releases.
For example, you may need to do a data fix to a field that had an incorrect date format applied during an upgrade, and rather than initiate a formal release train and application release for this, you could expedite the change by creating an independent release package and sending it through the simpler workflow to deployment.
Independent release packages enable you to deploy urgent or low-impact changes into production quickly while still leveraging the visibility, automated deployment, and audit trail capabilities of Serena Release Manager.
|
Direct associations with release packages include the following:
Development Change Requests represent delivered changes from the development process and are typically associated with tickets from development management systems. Examples include SBM incidents or issues, Dimensions CM requests, and Rally defects.
Deployment Units represent a set of deployable components. Examples include Dimensions CM baselines with build outputs, Serena Development Manager development packages, and ChangeMan ZMF change packages.
Deployment Tasks are actions to be executed as part of the deployment process to deploy a release package into a specific environment. Deployment task types include manual, vault, and automation. Within these types are various sub-types.
Deployment Process Templates enable you to create and copy sets of deployment tasks for reuse in different stages, release packages, and applications.
Other attributes that control release packages are as follows:
Release Types are used to determine the stages release packages are deployed through. In the default implementation of Serena Release Manager, release types include major, minor, and emergency.
Release Stages are the gates that the release goes through on its path into production. The default stages provided are integration test, user acceptance test (UAT), and production deployment. A stage may have one or more environments related to it. Releases may be deployed into an environment based on availability.