Glossary

This glossary contains terms that are relevant to the BMC Release Process Management product.

activity logs

Activity logs audit changes made to the request and step process models in BMC Release Process Management, usually through the following modes:

User interaction in the product user interface
Automatic request and step completion
Additional calls through REST or integration frameworks

application

An application represents the software unit necessary for the deployment process. An application comprises various components that are mapped to different environments. For more information, see Managing applications.

argument

Arguments (also known as parameters) are code blocks used in automation scripts. Arguments are set in a triple-commented block so that they do not get executed with the script. Arguments use YAML format, which is a simple indent and colon notation. The argument name is defined followed with a colon. Any indented lines under the argument name are considered to be attributes of that argument.

attribute

The indented lines under the argument name are considered to be attributes of that argument. Attributes are indented with two spaces followed by a colon and a value in the script body of an automation script. Arguments can be of two types:

Input attributes are the input information that you provide in a step. These input attributes are needed to execute the action that you want to perform using the automation script.
Output attributes define the results that you want to see after the automation script runs and the step is completed.

For a list of input and output attributes that you can use in the script body of an automation script, see Input and output attributes for arguments.

automation

Automation is a process of automating manual tasks or performing functions in an external system with the help of automation scripts. For more information, see Managing automation.

automation script

For every action that you want to perform in an external system (target) using BMC Release Process Management, you need an automation script. An automation script usually contains a block of Ruby script that defines what action must be performed, how it must be performed, and the underlying mechanism for performing the action. You can use automation scripts in a step of a request and then run the request to actually execute the action. For more information on creating automation scripts, see Creating data retriever scripts.

authentication

This product enables you to authenticate users in two ways, either at the time of installation or after configuring the product:

Local user database authentication: This refers to the user name and password authentication that you use to access the product and that gets stored in the local database. This authentication checks if you are a valid user and gives you access to your account.
External authentication mechanism: (Optional) This authentication enables you to use the LDAP server or the CAS server.

For more information, see Setting the external authentication.

bulk delete request

This request allows you to select multiple requests to delete at one time and enables you to filter requests in different ways and delete them as selected.

For more information, see Deleting bulk requests.

component

Components form pieces of an application and are assigned to various environments for the purpose of deployment.

For more information, see Managing components.

Dashboard

The Dashboard provides a customized view of the applications, environments, and components existing in your database. The Dashboard also includes a list of requests recently active in the system. For more information, see Navigating the interface.

data retriever script

An automation script in the Ruby programming language that runs on the target server to obtain the necessary configuration data.

environment

An environment represents a set of servers grouped together for a particular purpose in the deployment process. Environments can be of various types depending on the purpose for which they are created. For example, development environment, QA environment, staging environment, production environment, and so on.

For more information, see Managing environments.

external ticket filters

This is a mechanism that enables you to retrieve tickets from an external system into BMC Release Process Management.

For more information, see Managing tickets.

group

A group is logical management unit for users such as “Quality Assurance” or “Database Admins” that is primarily used for reporting purposes. Groups represent the functional groups in your organization and might have up to two managers.

For more information, see Managing groups.

inherited environment

If an environment name used in the request of the step matches the environment name in BRPD, then such environment is selected by default in the step and is suffixed with the text (inherited from request).

installed component

These are component instances assigned to an application and an environment in a request. Installed components are unique to an environment and application, and are stored with unique versions and property values. This object is not available on the user interface. When a component is selected for a step and assigned to an environment for an application, or the component is modified in some way in the REST API, the model used in the background is an installed component.

job run

Job runs are models that track the progress of automated background processes (that are a part of a request or step) in BMC Release Process Management.

list

Lists are used for maintaining various options lists inside BMC Release Process Management. System lists are installed by default and cannot be archived or deleted.

local ruby script

An automation script in the Ruby programming language that runs on the agent host of the engine that starts an automation step.

For more information, see Creating local ruby scripts.

local shell

An automation script that runs on the agent host of the engine that starts an automation step and can be written in any interpreted language available on the engine server.

For more information, see Creating local shell scripts.

notification template

Notification templates are user customizable email templates that are used by BMC Release Process Management notification systems (system events) for request or steps. Templates use the LIQUID template framework to allow tokenized values.

For more information, see Managing notification templates.

owner

The user that has been assigned on-going responsibilities for requests.

package content

Package content can be used to associate a request with labels for software packages, with file names or with source codes. You can add package content in the metadata and link a request for one or more of them.

phase

The phase represents how the work gets done. Phases categorize steps across multiple requests. Many release plans are organized into phases such as the "week before prep" or "night before tasks" or "after deploy checks". You can use phases as gates for step execution by adding runtime phases. You can use phases in different scenarios such as:

Runtime execution: Several steps can be grouped into a phase called "post deploy checks". For this phase, you can use two runtime phases: "promote" and "wait". You can use these steps as a procedure that resets test data and notifies the Quality Assurance team. You can set a condition on the procedure so that it only executes promotion notifications if the runtime phase is set to promote.
Request consolidation: Several developers are coming up with the steps for a release and each developer builds a request. As a release manager, you need to merge all the requests together but match the order of execution in the blended request under a release plan. You can use the Consolidate Requests feature to bring all the selected requests together and organize the steps by phase.

plan template

Plan templates include information about the stages, request templates, and the security properties for a release plan. This entity is a model that can be used to create multiple plans.

process

A process (same as a business process) is used to categorize requests for planning and reporting purposes.

procedure

A procedure is a reusable collection of steps that can be placed one or more times in a request. If a suite of steps is used over and over again in other requests, you can make a procedure out of it. For more information, see Managing procedures.

project

A project provides flexible and structured management of the release and deployment process that can be used to organize requests and releases.

promotions

Promotions is a mechanism that can be used to move applications from one environment to the other.

property

Each step in a request can determine which servers and components are affected during execution. Steps can also draw properties assigned to those components. Properties are the place to store settings data and values that are important to the execution of requests. When you put values such as “classpath” in properties, the same value is mapped to each request working with those components in those environments. Properties can be assigned property values (default values), installed components, application components, requests, servers, and server levels.

release

A release is an application version with a specific set of components and their versions that can be deployed through the stages of a route.

release tag

A release tag is a categorization that you can apply for a specific software version (application) or a project that can be applied to plans and requests.

release tag template

A release tag template is a template that is used to autoincrement the release versions.

remote dispatcher script

An automation script in the Ruby programming language that runs on the engine server and implements various transport protocols (agent types) for transferring files and executing scripts on remote servers.

remote shell

An automation script that runs on the target server, performs actions specific to the target server, and can be written in any interpreted language available on the target server.

request

Request is a main unit of deployment in this product. A request represents the mechanism used to deploy one or many components of an application into an environment. Requests contain the work to be done in the deployment process. Requests are comprised of steps, which can be manual (for example, check logs for errors) or automated (for example, deploy package using one of the automation scripts). Requests and steps can be assigned to users and scheduled on the calendar. They have a duration and due dates, and are planned. Requests follow a series of states and transitions from planned to complete. Requests are created as part of a plan or a project.

request property

Request properties are properties that can be used within a request and represent input arguments that can be used in the automation scripts of the steps.

runtime request property

Runtime request property is a property which is created during the request runtime and cannot be accessed from the UI.

requester

The user that creates or initiates a request.

request template

Request templates can be used as a model for creating additional requests in the future. For example, developers use the same steps for bug fixes in numerous requests. By creating a request with all the relevant steps needed, a request can become a template that can be used repeatedly instead of constructing the steps over and over.

request ID

An attribute of a request that helps you uniquely identify a request. The request ID begins at the base number that you set at the time of installation.

route

An application object that allows you to map route gates.

route gate

An assignment of a certain environment to a stage in a plan.

run

An ordered collection of requests that can be executed serially or in parallel as a deployment activity. You can schedule multiple runs for different dates and time.
A plan stage might require one or more runs to complete all the tasks for that stage.

stage dates

Stage dates is a scheduling mechanism that allows you to add beginning and ending dates for a release plan (or lifecycle) and is used primarily for reporting and charting.

server

A server is a resource such as a physical server or a virtual machine that can be assigned to environments. Components are assigned on servers. Servers can be grouped into server groups. Servers can also be categorized into server levels, depending on their functional use such as "JBoss servers" or "Load Balancers." See Server groups and server levels.

server group

A collection of servers that can be assigned and treated as a group (unit) in steps.

server level groups

A collection of server level instances. This group is created to categorize servers by their capability or functional use; for example, JBoss servers or Load Balancers.

step

Steps represent a unit of work created under a request and can be characterized as a part of a task (for example, pre-deployment checks). Steps can also be categorized by Phase or Runtime Phase such as “night before work”. Steps are completed in series, in the following ways:

One after the other, where each one must be completed before starting the next
Parallel, where execution may proceed asynchronously to reflect different dependencies in the work
Anytime steps, which may be completed anytime during the request, but must be completed so that the request under which it is assigned is completed

team

A team is a collection of users to which access permissions for various objects and application areas are assigned. Teams can be used in conjunction with groups to bring users from different groups (for example, Database Administrators, Developers) into a single team to allow access to particular applications or environments.

ticket

A ticket is a generic representation of an external tracking model that allows external ticketing systems to connect to plans or steps in a request (for example, Change requests in BMC Remedy). BMC Release Process Management enables you to integrate with external systems and enable automation of steps using tickets.

ticket summary report

The ticket summary report displays a request list per ticket, application, and run.

user

Users are the base level entity with a login ID. A user represents a person and can be local to the application or derived from a central authentication server such as LDAP. Users have one or many roles that they play, such as deployer or coordinator with specific rights granted for each role. Users can be members or one or many groups. Users may also be part of teams. Users have a specific profile, team assignments, group assignments, and permission settings.

version tag

Version tags are controlled vocabularies for installed components that manage the range of valid versions that can be assigned in a step. These values may be manually entered in the metadata interface or added programmatically by an external repository system.

version conflict report

The version conflict report tells you how to find components versions conflicts in the runs. If you discover conflicts of versions, you need to go back to the runs to sort this out.

work task

A work task provides you the capability to categorize steps across multiple requests by task.

Page tree