Share this page

# Scenario 8: Deploy requests by actioning

An alternative way to deploy requests is to use action driven deployment.

This scenario is similar to Scenario 2: Deploy requests to a single deployment area. The main difference is that some of the request lifecycles states are mapped to the GSL.

Note: To run this scenario, first set up the environment, as described in Prerequisites.

In this topic:

## About actioning to a lifecycle state

When a request is actioned to a lifecycle state that is mapped to a stage in the GSL, the request is automatically promoted to that stage. If the Deploy by Default option is enabled for that stage’s deployment area, the request is automatically deployed to the area.

This scenario uses the following extended lifecycle for enhancement requests:

The following table shows request lifecycle states that are mapped to stages in the GSL.

Request lifecycle state | Mapped to GSL stage
--- | ---
Raised | DEV
Under Work |
In Test | SIT
Ready for QA | QA
In QA |
Ready for Pre-Prod | PRE-PROD
In Pre-Prod |
Ready for Live |
In Live | LIVE
Closed |

Back to top

## Scenario overview

This scenario does not contain detailed steps. It includes the following tasks:

Step 1: Rita, the release manager, performs these tasks. | Raises an enhancement request to manage the change that is required to the Qlarius web application. By default the request is at the DEV stage when it is created. Delegates the request to Ted, the team lead. Actions the request to its next lifecycle state, Under Work. The request is removed from Rita’s Request inbox.
Step 2: Ted performs these tasks. | Does some design work to see what part of the application is affected. Primes a child task from the request. By default, the task is at the DEV stage when it is created. Delegates the task to Dinesh, a developer. Actions the task to its next lifecycle state, Under Work. The task is removed from Ted’s Request inbox.
Step 3: Dinesh performs these tasks. | Updates his work area from the stream. Modifies the sources. Delivers the changes to the stream and relates them to the task. Deploy by Default for the DEV area is enabled, so the sources are automatically deployed. Delegates the task to Ted, the team lead, for peer review. Actions the task to the next lifecycle state, Peer Review. The task is removed from Dinesh’s Request inbox.
Step 4: Ted performs these tasks. | Performs a peer review. Actions the task to its final state, Closed. The task is removed from Ted’s Request inbox. Actions the request to the In Test state. Because this lifecycle state is mapped to the SIT stage, the request and child tasks are automatically promoted to the SIT stage. Deploy by Default for the SIT area is enabled, so the request and task are automatically deployed. Performs system integration tests. Actions the request to the Ready for QA state. Because this state is mapped to the QA stage, the request and child task are automatically promoted to the QA stage. Because of the separation of duties, the team lead cannot deploy the request and task to QA (Deploy by Default is not enabled for the QA deployment area).
Step 5: Tao performs these tasks. | Actions the request to the In QA state. Deploys the request and child task to the QA deployment area. Delegates the request to a QA engineer who tests the request. After completing the tests, the engineer delegates the request back to the QA manager. Actions the request to the Ready for Pre-Prod state. Because this state is mapped to the PRE-PROD stage, the request and child task are automatically promoted to the PRE-PROD stage. Because of the separation of duties, the QA manager cannot deploy the request and task to PRE-PROD (Deploy by Default is not enabled for the PRE-PROD deployment area).
Step 6: Rita performs these tasks. | Actions the request to the In Pre-Prod state. Deploys the request and the child task to the PRE-PROD deployment area. Delegates the request to a release engineer who tests the request. After completing the tests, the release engineer delegates the request back to Rita. Actions the request to the Ready for Live state. During the regular maintenance period when the LIVE deployment area is offline, actions the request to the In Live state. Because this state is mapped to the LIVE stage, the request and child task are automatically promoted to the LIVE stage. Deploy by Default is not enabled for the LIVE stage, so no deployment takes place with the promotion. Deploys the request and child task to the LIVE deployment area. Actions the request to its final state, Closed. Raises an enhancement request to manage the change that is required to the Qlarius web application. By default the request is at the DEV stage when it is created. Delegates the request to Ted, the team lead. Actions the request to its next lifecycle state, Under Work. The request is removed from Rita’s Request inbox.
Step 7: Ted performs these tasks. | Does some design work to see what part of the application is affected. Primes a child task from the request. By default the task is at the DEV stage when it is created. Delegates the task to Dinesh, a developer. Actions the task to its next lifecycle state, Under Work. The task is removed from Ted’s Request inbox.
Step 8: Dinesh performs these tasks. | Updates his work area from the stream. Modifies the sources. Delivers the changes to the stream and relates them to the task. Deploy by Default for the DEV area is enabled, so the sources are automatically deployed. Delegates the task to the team lead for peer review. Actions the task to the next lifecycle state, Peer Review. The task is removed from Dinesh’s Request inbox.
Step 9: Ted performs these tasks. | Performs a peer review. Actions the task to its final state, Closed. The task is removed from Ted’s Request inbox. Actions the request to the In Test state. This lifecycle state is mapped to the SIT stage therefore the request and child tasks are automatically promoted to the SIT stage. Deploy by Default for the SIT area is enabled so the request and task are automatically deployed. Performs system integration tests. Actions the request to the Ready for QA state. This state is mapped to the QA stage therefore the request and child task are automatically promoted to the QA stage. Because of the separation of duties the team lead cannot deploy the request and task to QA (Deploy by Default is not enabled for the QA deployment area).
Step 10: Tao performs these tasks. | Actions the request to the In QA state. Deploys the request and child task to the QA deployment area. Delegates the request to a QA engineer who tests the request. After completing the tests the engineer delegates the request back to the QA manager. Actions the request to the Ready for Pre-Prod state. Because this state is mapped to the PRE-PROD stage, the request and child task are automatically promoted to the PRE-PROD stage. Because of the separation of duties, the QA manager cannot deploy the request and task to PRE-PROD (Deploy by Default is not enabled for the PRE-PROD deployment area).
Step 11: Rita performs these tasks. | Actions the request to the In Pre-Prod state. Deploys the request and the child task to the PRE-PROD deployment area. Delegates the request to a release engineer who tests the request. After completing the tests, the release engineer delegates the request back to Rita. Actions the request to the Ready for Live state. During the regular maintenance period when the LIVE deployment area is offline, actions the request to the In Live state. Because this state is mapped to the LIVE stage, the request and child task are automatically promoted to the LIVE stage. Deploy by Default is not enabled for the LIVE stage, so no deployment takes place with the promotion. Deploys the request and child task to the LIVE deployment area. Actions the request to its final state, Closed.

Back to top

https://admhelp.microfocus.com Dimensions CM 8942
Tips to improve your search results... OpenText™ Dimensions CM Help Center OpenText™ Dimensions CM Help 25.2 All View Local Help Center View Online Help Center Version: