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 don’t 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 the inputs that you can provide in a step. These inputs are needed to execute the action that you want to perform by using the automation script.
- Output attributes define the results that you want to see after the automation script is run 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) by 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 for actually executing the action. For more information on creating automation scripts, see Creating-resource-automation-scripts.
authentication
This product enables you to authenticate users in 2 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 for accessing 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
Allows you to select multiple requests to delete in one go. Enables you to filter requests in different ways and delete them as per choice.
component
Components form pieces of an application, that 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. This also includes a list of requests recently active in the system. For more information, see Navigating-the-interface.
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 mostly used for reporting purposes. Groups represent the functional groups in your organization and groups might have upto two managers.
installed component
These are component instances assigned to an application and an environment in a request. Installed components created 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 some details of the component is modified 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.
notification template
These are user customizable email templates that is used by BMC Release Process Management notification systems (system events) for request or steps. Templates use the LIQUID template framework to allow tokenized values.
owner
The user that has been assigned on-going responsibilities for requests.
package content
Package content can be used for associating a request with labels for software packages or file names or 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 a flexible and structured management of the release and deployment process that can be used to organize requests and releases.
promotions
This 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 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 (same as 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.
request
Request is a main unit of deployment in this product. A request represents the request 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 duration, planned and due dates. They follow a series of states and transitions from planned to complete.
Requests can be created as a part of a plan or a project.
requestor
The user that creates or initiates a request.
Request template
Request templates can be used as a model for creating additional requests. This is a request that can be used as a template in future. For example: Developers use the same steps for bug fixes in numerous requests. They can use a request with all the relevant steps and turn it into a template rather than construct 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 u must have set at the time of installation.
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 may require one or more runs to complete all the tasks for that stage.
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 levers 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 as per their capability or functional use. For example, JBoss servers or Load Balancers.
stage dates
This is a scheduling mechanism that allows you to add beginning and end dates for a release plan (or lifecycle) and is mostly for reporting and charting.
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 may be 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. These 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 allow 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 request list as per ticket, application, and run.
user
Users are the base level entity with a logon 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
This 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.