Scenario 2: Deploy requests to a single deployment area
This scenario demonstrates how to deploy Dimensions CM requests to modify the Qlarius web application. Deployment is to a single deployment area at each stage.
This scenario is similar to Scenario 1: Basic request deployment. The main difference is a build at the DEV stage.
Note: To run this scenario, first set up the environment, as described in Prerequisites.
Scenario overview
-
The release manager raises an enhancement request.
-
The development team lead primes a child task from the request.
-
A developer makes a modification, delivers the modification and relates it to the task, builds the task, and captures the build outputs in Dimensions CM.
-
The team lead promotes and deploys the request and task to the SIT stage and deployment area, and then promotes them to the QA stage.
-
The QA manager deploys the request and task to the QA deployment area and then promotes them to the PRE-PROD stage.
-
The release manager deploys the request and task to the PRE-PROD deployment area and then promotes and deploys them to the LIVE stage and production environment.
Scenario information
-
The following stream is used: QLARIUS:JAVA_BRANCHA_STR
-
There is a separation of duties between the employees at the following stage transitions:
-
SIT to QA
-
QA to PRE-PROD
-
-
A build is only required at the DEV stage.
-
Deployment is to a single deployment area at each stage. The following deployment areas are used:
Stage | Deployment area | Deploy by Default enabled on area? |
---|---|---|
DEV | LCL_DEV_JBRNCHA_AREA03 | Yes |
SIT | LCL_SIT_JBRNCHA_AREA03 | Yes |
QA | LCL_QA_JBRNCHA_AREA03 | No |
PRE‑PROD | LCL_PP_JBRNCHA_AREA03 | No |
LIVE | LCL_LIVE_JBRNCHA_AREA03 | No |
For a list of the promotion and deployment privileges required by the users see Scenario privileges.
Scenario prerequisites
Before you can run this scenario, create a work area on your local machine for the user Dinesh, for example:
C:\streams\JAVA_BRANCHA_STR\dinesh
Run the scenario
The following table describes the tasks performed in this scenario.
Action | Procedure |
---|---|
The release manager raises an enhancement request. |
Changes are required to the Qlarius web application. Rita, the release manager, raises an enhancement request to manage the change.
The new request is added to Rita’s request inbox with the following ID: QLARIUS_CR_n. By default, the request is at the DEV stage when it is raised. |
The release manager delegates the request to the team lead. |
Rita delegates the request to the development team lead, Ted, whose team is responsible for maintaining Qlarius.
The wizard closes automatically. Dimensions CM sends an email to Ted notifying him that a request has been added to his Request inbox. |
The release manager actions the request to its next state. |
Rita actions the request to its next state, UNDER WORK.
|
The development team lead primes a child task from the request. |
Ted reads the email, views the request in his Request inbox, and does some design work to see what part of the application is affected. He then primes a child task from the request.
The new child task is added to Ted’s request inbox with the following ID: QLARIUS_TASK_n By default the child task is at the DEV stage when it is raised |
The development team lead delegates the task to a developer. |
Ted delegates the child task to a Dinesh, one of the developers in his team.
The wizard closes automatically. Dimensions CM sends an email to Dinesh notifying him that a task has been added to his Request inbox. |
The development team lead actions the task to its next state. |
Ted actions the task to its next state, UNDER WORK.
|
The developer updates their work area from the stream. |
Dinesh reads the email and checks his Request inbox. He does some research and identifies the item that needs to be modified, LifeQuote.java. He updates his work area from the stream.
Dinesh’s work area is updated. |
The developer modifies the item. |
In Dinesh’s local work area edit the item, LifeQuote.java. For the purpose of this scenario make a minor edit, for example, add a comment to the top of the item. |
The developer delivers the item and relates it to the task. |
Dinesh delivers the modification to the stream and relates it to the child task.
|
The developer verifies that the item was automatically deployed to the DEV area. |
Deploy by Default is enabled for the DEV area, so when Dinesh delivered the item it was automatically deployed. He checks that the item was successfully deployed.
|
The developer builds the task and captures the outputs. |
Dinesh builds the task in the DEV deployment area and captures the build outputs in Dimensions CM against the task.
|
The developer verifies that the build was successful and that the outputs were captured in Dimensions CM and deployed. |
Dinesh verifies that the build was successful and that the outputs were captured in Dimensions CM against the task and deployed to the DEV deployment area.
|
The developer delegates the task to the team lead. |
Dinesh delegates the task to Ted for peer review.
The wizard closes automatically. Dimensions CM sends an email to Ted notifying him that a task has been added to his Request inbox. |
The developer actions the task to its next state. |
Dinesh actions the task to its next state, PEER REVIEW.
|
The team lead does a peer review and actions the task to its final state. |
Ted has read his email, seen the task in his Request inbox, done a peer review of the item that Dinesh modified, and is satisfied with the changes that he made. He actions the task to its final state, CLOSED.
The child task is removed from Ted’s request inbox. |
The team lead promotes and deploys the parent request to the SIT stage. |
To perform system integration testing, Ted promotes and deploys the parent request and task to the SIT stage and its associated deployment area. Deploy by default is enabled for the SIT area. A build is not required at the SIT stage so the team lead uses an area filter to only deploy the items that are required for testing at SIT (the executables).
|
The team lead verifies that promotion and deployment were successful. |
Ted verifies that promotion and deployment operations were successful and that the executables were deployed to the SIT area.
|
Ted performs system integration testing. | |
The team lead promotes the request and task to the QA stage. |
System integration testing has been completed successfully so Ted promotes the request and task to the QA stage. Deploy by Default is not enabled so the request and task cannot be automatically deployed to the QA deployment area.
|
The team lead actions the request to its next state. |
Ted actions the request to its next lifecycle state, IN TEST.
|
The QA manager deploys the request and task to the QA deployment area. |
Tao reads the email, checks her Request inbox, and deploys the request and task to the QA deployment area. A build is not required at the QA stage so the QA manager uses an area filter to only deploy the items that are required for testing at QA (the executables).
|
The QA team tests the application. | |
The QA manager promotes the request and task to the PRE-PROD stage. |
QA testing has been completed successfully so Tao promotes the request and task to the PRE-PROD stage. Deploy by Default is not enabled so the request and task cannot be automatically deployed to the PRE-PROD deployment area.
|
The QA manager actions the request to its final lifecycle state. |
Tao closes the request.
|
The release manager deploys the request and task to the PRE- PROD deployment area. |
Rita reads the email, checks the Pending tab for the PRE-PROD stage on the Deployment view. Rita sees that the request and task are ready to be deployed to PRE- PROD. A build is not required at the PRE-PROD stage, so the release manager uses an area filter to only deploy the items that are required at PRE-PROD (the executables).
|
The release team tests the application. | |
The release manager promotes the request and task to the LIVE stage. |
Testing has been completed successfully so Rita promotes the request and task to the LIVE stage. Deploy by Default is not enabled for the LIVE deployment area.
|
The release manager deploys the request and task to the LIVE deployment area. |
Let’s assume that it is now the regular maintenance period when the LIVE deployment area is offline. Rita checks to see what requests are ready to be deployed to the LIVE stage and uses an area filter to only deploy the executables.
|
The release manager verifies that the deployment operation was successful. |
Rita verifies that the deployment operation was successful.
|
The release manager verifies that the executable was deployed. |
Rita verifies that the executable was deployed to the LIVE area.
|
End of scenario |
Scenario privileges
The tables below list the promotion and deployment privileges required by the users in the above scenario.
Promotion privilege | Privilege owner | Required at these stages |
---|---|---|
REQUEST_PROMOTE_NEXTSTAGE ITEM_PROMOTE_NEXTSTAGE | Team lead | DEV SIT |
QA Manager | QA | |
Release Manager | PRE-PROD |
Deployment privilege | Privilege owner | Required for these areas |
---|---|---|
The DEV and SIT areas are Deploy by Default areas, and no deployment privileges are required. | ||
REQUEST_DEPLOY ITEM_DEPLOY |
QA Manager | LCL_QA_JBRNCHA_AREA03 |
Release Manager | LCL_PP_JBRNCHA_AREA03 LCL_LIVE_JBRNCHA_AREA03 |