Before you use Serena Release Control, you should know the basic terminology and how the primary elements are related.
Release Trains provide a published schedule of changes to production. One or more application releases are associated with each release train.
Application Releases represent versions of applications or projects, where the application or project architecture is specified by components. One or more release packages are associated with each application release.
Release Packages represent a portion 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.
Development Change Requests represent delivered changes from the development process and are typically represented as tickets from development management systems. For example, these may be Serena Release Vault requests or SBM tickets used to manage development processes.
Deployment Units represent a set of deployable components, such as a Serena Release Vault baseline with build outputs.
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.
Deployment Process Templates enable you to create and copy sets of deployment tasks for reuse in different stages, release packages, and applications.
Release Types are used to determine the stages release packages are deployed through and to drive release policies on what types of changes may be delivered for release trains. 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. Typical stages in a release are integration test (INT), product test (PT), user acceptance test (UAT), pre-production (PRE) and production (PROD). Some organizations may also have a stage for disaster recovery (DR) which is updated after production deployment. A stage may have one or more environments related to it. Releases may be deployed into an environment based on availability.