Glossary

Applications: Release Control applications are logical representations of real-world applications that are being released as part of release trains or release packages. Application examples include a software product, a set of related components, and shared services. You may assign an application version to a release package to track that information.; SBM applications comprise the elements needed to support processes used by teams of people. All applications contain a single primary table that stores process items and, optionally, one or more auxiliary tables used for storing auxiliary data that supports the process. Applications also contain workflows that determine the flow of items through the process, fields that store data, forms for viewing and adding data, roles that control access, and more.
Approvals: Approvals may be required to allow a release train to proceed to the final deployment stage; to validate that a release train may exit a stage based on stage gate exit criteria; to confirm that pre-defined milestones for release trains have been reached by a certain date; and to deploy into environments.
Collections: Collections are the lists of objects that you work with as part of Release Control, such as requests, deployment units, and deployment tasks. These are populated by collection widgets.
Deployment Paths: Sequences of environments through which release packages progress during the release cycle.
Deployment Tasks: Include the details of what is to be deployed, what order they are to be deployed in, and what needs to be done before, during, and after they are deployed.

Deployment Units: A packaged set of deployment-ready files and metadata that is associated with a deployment task. Examples include Deployment Automation component versions, Dimensions CM baselines, and ChangeMan ZMF change packages.
Environment Groups: Logical representations of two or more related environments. These can be added to deployment paths.
Environments: Logical representations of the physical environments used by your organization. Typical environments include testing, staging, and production. These can be added to deployment paths.
Gates: Points in the workflow where exit criteria may be validated and approved as met before the release train can move to the next stage. In the default implementation, gates are defined at the end of some of the release train stages and are monitored through exit criteria.
Milestones: Date-based activities against which progress can be measured. Milestones are typically interim deliverables within a life cycle stage.
Plugins: Plugins are used to implement the integrations between Release Control and other products.
Process Apps: A process app includes one or more applications used to track items through workflow processes. A process app can also include one or more orchestrations that provide the logic for the invocation of web services.
Release Approvals: Built-in approval items that may be required for the release train. Up to four levels of approval may be defined for each of these.
Release Data: A process app whose main purpose is to manage the release data for Release Control, such as release type and application version.
Release Elements: Entities or objects that support your release processes, such as applications, environments, release types, and deployment paths.
Release Packages: Contain all the information needed to deploy deployment units to or run processes in environments.
Release Trains: Calendar-based management of a set of release packages across various life cycle stages. You can use planning or deployable release trains.
Release Type: A user-defined category for release trains and release packages. Release type values are stored in the Release Data process app's auxiliary data, and you can easily add values that are appropriate for your implementation.
Requests: Represent work items in response to a business need.
Single Sign-on (SSO): Software that enables a user to log in to a Web-based Serena product or component, and be recognized on subsequent accesses to that product or components. This software also provides the ability for security tokens to be used in an orchestration, allowing Web services to be called without requiring the user to provide credentials at inconvenient times.
Stages: Logical divisions of the process app workflows that represent a roll-up of the states within the swimlanes of the workflow.
States: A state is a position in an application workflow where a primary item resides. A state provides accountability as items are transitioned through the workflow process. While an item is in a given state, it has a primary owner who is responsible for performing a specific task with the item before it can be transitioned to the next state. You can also set up an application workflow so that one or more users have secondary responsibility for items while they are in a particular state.
Task Templates: Templates of ordered deployment tasks.
Timelines: Present the overall status for release trains in a Gantt chart format.
Transitions: Transitions are used to take action on objects implemented as SBM items, such as release trains and release packages. Transitions are used to submit new items, move items to a different state, update items, and delete items. Most transitions are available as buttons on state forms. You click a transition button to initiate the transition. In most cases, you can enter data about an item on a transition form before completing the transition.