Glossary
This glossary contains a list of key terms commonly used in Deployment Automation.
Agents |
Agents are physical resources for deployment. To run a
deployment, an agent must be installed on the target
server. |
An agent pool is a set of agents that is logically grouped
together. |
|
Agent relays are used to manage communication between
servers and agents. Agent relays are typically used when
agents are dispersed across geographic locations or must
communicate through firewalls. Agent relays can also be
used to manage network traffic in implementations where you
have many agents. |
|
ALF (Application Lifecycle Framework) is an integrative
layer for some OpenText products. These events can be
used for custom integrations from SBM to Deployment Automation. |
|
Aliases are alternate names that are assigned to agents and
agent relays when configuring mutual authentication. |
|
Applications bring together components with their
deployment targets and orchestrate multicomponent
deployments. |
|
Application environments are environments that have been
added to an application. Each application environment has
its own set of operations and data within the context of
the application, including inventory and compliance status.
Environments can be added to multiple applications
individually or as part of pipelines. |
|
Application processes are typically configured from
processes defined for their associated components. |
|
An application task is used to interrupt an application
process until some manual intervention is performed. |
|
Approvals enable process requests to run in application
environments that require them. |
|
Approval processes tell Deployment Automation what to do
when an application environment requires approval. |
|
Artifacts are files, images, databases, or other software elements associated with
components. |
|
See CodeStation. |
|
Authentication realms determine a user's identity within an
authorization realm. |
|
Authorization realms associate users with roles and work
with authentication realms to determine which users can
access Deployment Automation. |
|
A blackout of a date means that no deployments can be
scheduled and no snapshots can be made on that date. A
blackout is set per environment, per application. |
|
CodeStation is an embedded repository that handles artifact versioning in Deployment Automation. You can direct Deployment Automation to
introduce artifacts into CodeStation from the file system
or from external source control tools that you identify
when you select the Source Config Type for
a component. |
|
An environment is compliant if the last requested processes
successfully ran in that environment. |
|
Components typically map to a functional part of a real
world application, and represent deployable items, or
artifacts, such as files, images, databases, and
configuration materials. |
|
Component processes define how the component should be
deployed, installed or interacted with. A process typically
contains a sequence of interdependent plugin steps,
and may include complex logic for actions to perform if a
step of the process fails. |
|
A component task is used to interrupt a component process
until some manual intervention is performed. |
|
Component templates enable you to save and reuse component
processes and properties and create components from
them; template-based components inherit the template
properties and processes. |
|
Component versions are instances of a Deployment Automation component. |
|
Configuration templates enable you to save and reuse
configuration data in processes. Typically, the data is for
server configurations, for example, on Tomcat servers, but
the data can be for any purpose. |
|
Deployment is a process request execution that results in
component versions or snapshots being installed onto one or
more target environments. |
|
Deployment packages enable you to deploy artifacts for multiple applications. They may also include component processes where components are shared among multiple applications and associated versions are to be deployed as part of the larger package. See Manage deployment packages. |
|
Environments represent logical deployment locations. Deployment processes must run in at least one environment.
Environments and their resources are used by applications
and components at runtime. |
|
You can export objects from a Deployment Automation server
and subsequently import
them into another Deployment Automation server. Export is
done on an object-by-object basis, whereas replication
export can alternatively be used to export an entire
application. |
|
Gates ensure that component versions or snapshots are
deployed into environments only if their status meets
certain conditions. |
|
Global processes are processes that are not associated with
a particular application or component. |
|
See Authorization Realms. |
|
You can
export
objects from a Deployment Automation server and
subsequently import them into another Deployment Automation
server. Import is done on an object-by-object basis,
whereas replication import can alternatively be used to
import an entire application. |
|
Inventory implies components, snapshots, and configurations deployed to
any resource. |
|
Inventory statuses can be applied to component versions
when they are successfully deployed to resources. |
|
Deployment Automation uses locks to ensure that processes
do not interfere with one another. |
|
Network relays can be used in multiple-server configurations to manage the communication between servers, and in disaster recovery server implementations. To configure server-to-agent communication for agent-initiated or server-initiated HTTP(S) communication, use Agent Relays. See Create network relays. |
|
Notification schemes define what events should generate
notifications and who should get these notifications. |
|
Notification templates define the format of the information
that you want to send in the email notifications for given
situations. |
|
In mutual authentication mode, communications are encrypted
as usual, but users are also required to authenticate
themselves by providing digital certificates. |
|
The output log is the Deployment Automation server log. |
|
A pipeline is a predefined sequence of environments in
which application process requests run. |
|
Plugins provide functionality in discrete steps to be used
in component and global processes for configuration of or
deployment into target environments. |
|
See Component Processes, Application Processes, Global Processes, and Approval Processes. |
|
Properties are parameters that are referenced in process
steps. |
|
Replication enables you to export and import whole sets of
Deployment Automation objects. |
|
Resources represent a deployment target on a Deployment Automation environment. Examples include physical machines,
virtual machines, databases, or J2EE containers. |
|
A resource group is a logical collection of resources.
Resource groups help you organize and manage the agents
installed in different environments throughout the network.
|
|
Roles provide the building blocks for the security system.
Roles have permissions that define the actions their
members, users or groups, can perform with product
features. |
|
The schedule option enables you to schedule application
processes and blackout dates for application environments.
|
|
SSL (Secure Socket Layer)
technology enables clients and servers to communicate
securely by encrypting all communications. |
|
Single sign-on (SSO) enables Deployment Automation to
integrate more easily with other OpenText products.
Login information is passed automatically through SSO. There is no need to prompt for login credentials as
information flows between products. |
|
A snapshot captures an application's current state, and as
the application moves through different environments, the
snapshot ensures that proper component versions are used.
|
|
You can apply and enforce conditions on application gates
based on snapshot statuses. |
|
A source config type is an integration from which you can load artifacts into
Deployment Automation as component versions. |
|
See Inventory Statuses, Snapshot Statuses, and Version Statuses. |
|
See Application Tasks and Component Tasks. |
|
Timelines show the number of processes run and graphical
indicators of success or failure. |
|
Tokens provide authorization for agents and users. |
|
See Authorization Realms. |
|
See Component Versions. |
|
You can apply and enforce conditions on application gates
based on component version statuses. |