- 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
- 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
- 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
- Deployment Units
- A packaged set of deployment-ready files and metadata that is
associated with a deployment task. Examples include
- Environment Groups
- Logical representations of two or more related environments.
These can be added to deployment paths.
- Logical representations of the physical environments used by
your organization. Typical environments include testing, staging, and
production. These can be added to deployment paths.
- 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.
- Date-based activities against which progress can be measured.
Milestones are typically interim deliverables within a life cycle stage.
- 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
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
- 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
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.
- 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.
- Task Templates
- Templates of ordered deployment tasks.
- Present the overall status for release trains in a Gantt chart
- 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. All rights reserved.