The main unit of deployment in BMC Release Process Management is a request. A request represents the deployment of the components of an application into an environment. A request describes the work to be done in the deployment process, such as putting an application in an environment, adding attributes, and packaging and deploying the software. A request is composed of steps, which can be manual (for example, “Check logs for errors”) or automated (for example, “Deploy package”) using one of the automation modules.
You can assign requests and steps to users and schedule requests on the calendar. Requests have a duration, a planned date, and a due date. They follow a series of states and transitions from planned to complete.
Through the BMC Release Process Management model, each step in the request can determine which servers and components are affected during execution. It can also draw on properties assigned to those components. Properties store settings and values that are important to the execution of requests. By putting values such as classpath in properties, you can ensure that the same value is mapped to each request that works with those components in those environments.
You can execute requests as part of a project, or as part of an application plan process or release plan.
Note
Starting with BMC Release Process Management 4.3.01.06 and later, if you associate a request to the application with the Strict plan control setting turned on, this request cannot be created, updated, or started, unless it has a plan and a plan stage assigned.
You can characterize steps as part of a task, such as “predeployment checks,” and also by phase or runtime phase, such as “night before work.” You can complete steps in series, where each one must be complete before starting the next, or in parallel, where execution proceeds asynchronously to reflect dependencies in the work. There are also “anytime” steps, which can be completed anytime during the request but must be complete to complete the request (for example, “update documentation”).
You can create a request in several ways, including from existing request templates. Request templates are particularly useful when you know that some steps will be repeated in several requests. Instead of constructing the steps over and over, you can take the request that has a complete set of information and steps and create a request template.
Note
Starting with BMC Release Process Management version 4.3.01.07 and later, you can see the request template that the current request was created from. To do this, in Requests > <Request_name>, see the Created from field.
This feature is available only for requests created in BMC Release Process Management version 4.3.01.07 and later.
When the request has a complete set of information, you can perform the release. You must change the request status from Created state to Planned. When the Planned request reaches its scheduled time, the Coordinator or Deployer can start the request execution. For more information about user permissions for managing the requests, see Administering users, roles, and access permissions.
You can create a request in three possible ways. They are as follows:
BMC Release Process Management allows you to create request templates from existing requests and use the template more than once if you require it. This is to save time to create requests over and over again.
Click Create Request. The request is created and the Request page opens. You can see the request ID at the top left corner.
You can add steps to the request. For more information about adding steps, see To add steps to a request.
You may choose an existing template and use it to create a request
You can add steps to the request. For more information about adding steps, see To add steps to a request.
You may have created one or more template and now you need to create a request from one of those templates.
You can add steps to the request. For more information about adding steps, see To add steps to a request.
After you have created a plan and edited plan details, you must create requests.
A release tag from a plan is inherited by the request created from the plan.
You can import a request to the system. But, for that you need to export a request and save it in .xml, .pdf, and .html format on your local machine.
You can import a request which you have stored as a XML file. BMC Release Process Management supports importing a file from your local machine in XML format. You can rename this request if you want.
Notification options indicate the list of participants who are supposed to receive the notifications for requests, changes in the request status, and so on.
Note
You can add or change the notification options only for a request with planned or created status.
For with BMC Release Process Management version 4.3.01.04 and earlier:
Starting with BMC Release Process Management version 4.3.01.05 and later:
From the Request Events list, select event request notification options.
Note
For the selected request events, the request Owner and Requestor always receive event notifications.
Select Notify Step Owner(s), if you want to send the request event notifications to all step owners.
From the Step Events list, select step notification options.
Note
For the selected step events, the step Owner always receives event notifications.
Select Notify all Step Owners from Request about changes to send the step event notifications for all the request steps to all step owners.
Select Notify Request's Owner/Requestor about changes to send the step event notifications for all the request steps to the request Owner and Requestor.
From the Notify on Step events list, select options to to send notifications for the step events.
From the Users list, select additional users to receive event notifications.
Only users that have access to the application associated with the request are available in the Users list.
There may be change of plans and so you may need to change the component versions associated with the request.
In a plan run, you can clone requests and execute requests in sequence or in parallel. For more information, see Managing plan runs.
You have created a request. Now you can add a plan to a request.
Note
Plan may have a route added to it. If the plan has a route added to it, you must create a request for certain stages of a plan using only the route environment defined in the route and mapped to the plan stage. For more information, see Adding a route to a plan.