- 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
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 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
- Auxiliary Tables
- Auxiliary tables are part of the architectural design of
They support but do not follow an application workflow, and can be used to
establish relationships between tables using relational fields.
- Collections are the lists of objects that you work with as part
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
- Deployment Units
- A deployment unit is a packaged set of deployment-ready files and
metadata that is associated with a deployment task. Examples include
- Environment Groups
- An environment group is a logical representation of two or more
related environments. These can be added to deployment paths.
- 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
- 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 are date-based activities against which progress can
be measured. Milestones are typically interim deliverables within a life cycle
- 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
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
- Release Items
- Release items is a general term used to refer to
items that are submitted as
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 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
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 are logical divisions of the process app workflows that
represent a roll-up of the states within the swimlanes of the workflow.
- 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.
- 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
- 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 are used to take action on objects implemented as
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.
Copyright © 2012–2017 Serena Software, Inc., a Micro Focus company. All rights reserved.