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.
Auxiliary Tables: Auxiliary tables are part of the architectural design of SBM. They support but do not follow an application workflow, and can be used to establish relationships between tables using relational fields.
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: Deployment paths are sequences of environments through which release packages progress during the release cycle.
Deployment Tasks: 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. See Failure Tasks and Task Templates.
Deployment Units: A deployment unit is 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: An environment group is a logical representation of two or more related environments. These can be added to deployment paths.
Environments: Environments are logical representations of the physical environments used by your organization. Typical environments include testing, staging, and production. These can be added to deployment paths and can be part of environment groups.
Failure Tasks: Failure tasks are executed in environments upon deployment or testing failure. They can be used to re-initialize environments to their original state or otherwise reconfigure environments. See Deployment Tasks.
Gates: Gates are points in the workflow where exit criteria may be validated and approved 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: Milestones are 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: Release approvals are 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: RLC - Release Data is a process app whose main purpose is to manage the release data for Release Control, such as release type and application version.
Release Elements: Release elements are entities or objects that support your release processes, such as applications, environments, release types, and deployment paths.
Release Items: Release items is a general term used to refer to Release Control items that are submitted as SBM items, such as release packages and deployable release trains.
Release Packages: Release packages contain all the information needed to deploy deployment units to or run processes in environments.
Release Trains: Release trains enable calendar-based management of a set of release packages across various life cycle stages. You can use planning or deployable release trains.
Release Type: Release types are user-defined categories 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. Release type is used to filter objects meant to be used for the same type of release, and limits selections such as release packages available for release trains and deployment paths available for deployable release trains and release packages.
Requests: Requests are release work items or technical or business requirements. These are populated from external tools through provider plugins.
Single Sign-on (SSO): Single sign-on (SSO) is 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: Stages are 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.
Tasks: Release Control tasks include deployment tasks, failure tasks, and tasks defined in task templates. In some cases, the term deployment tasks may be used in general to refer to all of these types of tasks.
Task Templates: Task templates hold sets of tasks and environment selections that can be used again for repeatable processes. These can be copied to and from deployable release trains and release packages to create deployment and failure tasks.
Timelines: Timelines present the overall status of release elements, such as release trains, in a Gantt chart format. A default timeline is provided, and administrators can change it or create others using the Timeline Manager.
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.