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.

Back to top

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.

Back to top

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

Back to top

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.

  1. Log in to the Dimensions CM web client as Rita.

  2. Switch to the following stream: QLARIUS:JAVA_BRANCHA_STR.

  3. In the Requests tab, in the toolbar, click New and select CR. The New Request dialog box opens.

  4. In the Title field, enter Implement support for Qlarius iPhone app.

  5. In the Detailed Description field, enter a description.

  6. In the Attributes tab, from the Severity/Priority list, select a value.

  7. Click Submit and then Close.

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.

  1. Select the request, and on the toolbar click Delegate. The Delegate wizard opens.

  2. Check that the Capability option is set to Secondary.

  3. From the Role to Delegate list, select IMPLEMENTOR and click Next.

  4. In the Candidate Users Authorized for Role Assignment list, select Ted and click Add.

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.

  1. Select the request, and on the toolbar select Action. The Action wizard opens.

  2. Check that the To Next State field is set to UNDER WORK.

  3. Click Finish and then OK. The request is removed from Rita’s request inbox.

  4. Log out of the web client.

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.

  1. Log in to the web client as Ted.

  2. Switch to the following stream: QLARIUS:JAVA_BRANCHA_STR.

  3. In the Requests tab, select the Request inbox and then the request that was raised by Rita.

  4. On the toolbar click Prime and select Task. The Prime Request dialog box opens.

  5. (Optional) Update the detailed description.

  6. Click Submit and then Close.

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.

  1. Select the child task and on the toolbar click Delegate. The Delegate wizard opens.

  2. Check that the Capability option is set to Secondary.

  3. From the Role to Delegate list, select IMPLEMENTOR and click Next.

  4. In the Candidate Users Authorized for Role Assignment list, select Dinesh and click Add.

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.

  1. Select the child task and on the toolbar select Action.

    The Action wizard opens.

  2. Check that the To Next State field is set to UNDER WORK.

  3. Click Finish and then OK. The child task is removed from Ted’s request inbox.

  4. Log out of the web client.

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.

  1. Log in to the web client as Dinesh.

  2. Switch to the following stream: QLARIUS:JAVA_BRANCHA_STR

  3. Change Dinesh’s work area to the one that you created earlier (see Prerequisites at the start of this scenario).

  4. In the Items view, on the Dirs tab of the navigation pane, expand Qlarius Underwriter > qlarius and select interfaces.

  5. On the toolbar click Update. The Update from Stream wizard opens.

  6. Click Next.

  7. Click Finish and then Close.

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.

  1. In the Items view, in the Dirs tab of the navigation pane, select interfaces.

  2. On the toolbar click Deliver. The Deliver to Stream wizard opens.

  3. Check that the Modifications option is selected.

  4. Click Next.

  5. Verify that LifeQuote.java is selected and click Next.

  1. In the Relate to Request(s) field, click Select. The Select Request dialog box opens.

  2. From the Product Name list, select QLARIUS.

  3. From the Type Name list, select TASK.

  4. Click Next.

  5. Select the task that is delegated to Dinesh and click Finish.

  6. In the Deliver to Stream wizard, click Finish and then Close.

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.

  1. Select the Deployment view.

  2. To display only information for the current stream, do the following:

    1. In the navigation pane, click the filter button in the top right corner.

    2. Select Show Current Stream.

  3. Check that the History tab is selected.

  4. In the navigation pane select the DEV stage node and then the LCL_DEV_JBRNCHA_AREA03 deployment area.

  5. In the content pane verify that LifeQuote.java was successfully deployed. The Event Result column should display Succeeded.

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.

  1. In the Requests tab, select the child task. In the toolbar, click Build, and select Build. The Run Build wizard opens.

  1. In the Build Configuration field, accept the default configuration.

  2. From the Build Stage list, select DEV.

  3. From the Build Area list, select LCL_DEV_JBRNCHA_AREA03.

  4. Click Next.

  5. Select the option Check in build outputs automatically. This checks the build outputs into Dimensions CM.

  6. To specify the request that the build outputs will be related to when they are checked into Dimensions CM, in the Specify the Request(s) field click Select. The Selection wizard opens.

  7. From the Product Name list, select QLARIUS.

  8. From the Type Name list, select TSK.

  9. Click Next.

  10. Select the child task that is delegated to Dinesh.

  11. Click Finish. The Selection wizard closes.

  12. In the Run Build wizard click Next.

  13. Accept the default build option selections (none), and click Next.

  14. Accept the default target selection options.

  15. In the target list, select Jar Files.

  16. Click Next.

    A summary of the build command that will be executed is displayed.

  17. Click Finish.

  18. (Optional) To monitor the progress of the build click the Job ID link.

  19. Click Close.

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.

  1. To verify that the build was successful, in the Deployment view select the History tab.

  2. In the navigation pane expand the DEV stage node, and select LCL_DEV_JBRNCHA_AREA03.

  3. In the content pane, verify that the Event Result column displays Succeeded for the following objects:

    • Lifequote.jar (the Event Type is Collect)

    • QLARIUS:JAVA_BRANCHA_STR (the Event Type is Build)

  4. Open Lifequote.jar, make a note of the item revision, and click Cancel.

  5. To verify that the build outputs were captured in Dimensions CM, in the Requests tab select the Request inbox and open the task. The Open Request dialog box opens.

  6. Select the Relationships tab and from the Related object class list, select Items.

    A list of all the build outputs that were captured in Dimensions CM against the task is displayed.

  7. Click Cancel.

  8. To browse the DEV deployment area, in the My Current Project view expand Deployment Areas > DEV Stage > LCL_DEV_JBRNCHA_AREA03

  9. Select the folder Qlarius Underwriter.

  10. In the content pane, verify that the latest revision of LifeQuote.jar was deployed.

The developer delegates the task to the team lead.

Dinesh delegates the task to Ted for peer review.

  1. In the Requests tab, select the Request inbox.

  2. Select the child task and on the toolbar click Delegate. The Delegate wizard opens.

  3. Check that the Capability option is set to Secondary.

  4. From the Role to Delegate list, select REVIEWER, and click Next.

  5. In the Candidate Users Authorized for Role Assignment list, select Ted and click Add.

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.

  1. Select the child task, and on the toolbar select Action. The Action wizard opens.

  2. In the New State section check that the To Next State field is set to PEER REVIEW.

  3. Click Next.

  4. In the Actual completed date field enter a date.

  5. In the Actual development effort (hours) field enter a number.

  6. Click Finish. The task is removed from Dinesh’s request inbox.

  7. Log out of the web client.

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.

  1. Log in to the web client as Ted.

  2. In the Requests tab, select the Request inbox.

  3. Select the child task, and in the toolbar click Action. The Action wizard opens.

  4. Check that the To Next State field is set to CLOSED.

  5. Click Finish and then click OK.

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).

  1. Select the parent request, and in the toolbar click Promote. The Promote wizard opens.

  2. Check that the Promote Child Requests option is selected.

  3. In the Next stage field, check that SIT is selected.

  4. Click Next.

  5. To deploy immediately, check that the option Perform Deployments is set to As Soon As Possible.

  6. In the Areas for Deployment field, select the LCL_SIT_JBRNCHA_AREA03 deployment area.

    Note: If both areas are selected, clear SIT LCL_SIT_JBRNCHA_AREA01.

  7. Click Next.

    A summary of the promotion and deployment activities and command that will be performed is displayed.

  8. Click Finish.

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.

  1. Select the Deployment view, and check that only the current stream is displayed.

  2. Check that the History tab is selected, and in the navigation pane select the SIT stage node.

  3. In the content pane, verify that the request was promoted successfully from DEV to SIT.

  4. In the navigation pane, expand the SIT stage node and select the LCL_SIT_JMAIN_AREA03 deployment area.

  5. In the content pane, verify that the request and child task were deployed successfully to the SIT deployment area.

  6. To browse the SIT deployment area, in the My Current Project view expand Deployment Areas > SIT Stage > LCL_SIT_JBRNCHA_AREA03.

  7. Select the folder Qlarius Underwriter.

  8. In the content pane verify that LifeQuote.jar was deployed.

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.

  1. In the Requests tab, select the Request inbox and then the request.

  2. In the toolbar, click Promote. The Promote wizard opens.

  3. Check that the Promote Child Requests option is selected.

  4. In the Next stage field, check that QA is selected. Click Next.

    Because Deploy by Default is not enabled, no deploy options are available.

  5. Click Next.

    A summary of the promotion activity and command that will be performed is displayed.

  6. Click Finish.

  7. In the Deployment view, select the History tab, and in the navigation pane select the QA stage node.

  1. In the content pane verify that the request was promoted successfully from SIT to QA.

The team lead actions the request to its next state.

Ted actions the request to its next lifecycle state, IN TEST.

  1. In the History tab, select the parent request. In the toolbar, click Action. The Action wizard opens.

  2. In the New State section, check that the To Next State field is set to IN TEST.

  3. Click Next.

  4. In the Details of Solution Given field, enter Lifequote updated.

  5. Click Finish.

    Dimensions CM sends an email to Tao, the QA manager, notifying her that a request has been added to her Request inbox.

  6. Log out of the web client.

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).

  1. Log in to the web client as Tao.

  2. Switch to the following stream: QLARIUS:JAVA_BRANCHA_STR

  3. Select the Deployment view, and check that only the current stream is displayed.

  4. Select the Pending tab.

  5. In the navigation pane expand the QA stage node and select the LCL_QA_JBRNCHA_AREA03 deployment area.

  6. In the content pane, from the Show list, select Requests.

  7. Select the request, and in the toolbar click Deploy. The Deploy wizard opens.

  8. Check that the Deploy Child Requests option is selected.

  9. Check that the Deploy Stage is set to QA.

  10. Click Next.

  11. To deploy the request and child task immediately, check that the option Perform Deployments is set to As Soon As Possible.

  12. In the Areas for Deployment field, check that the LCL_QA_JBRNCHA_AREA03 deployment area is selected.

  1. Click Next.

    A summary of the deployment activity and command that will be performed is displayed.

  2. Click Finish and click Close.

  3. Select the History tab.

  4. In the navigation pane expand the QA stage node and select the LCL_QA_JBRNCHA_AREA03 deployment area.

  5. In the content pane verify that the request and child task were successfully deployed to the QA area.

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.

  1. In the History tab, select the request.

  2. On the toolbar, click Promote. The Promote wizard opens.

  3. Check that the option Promote Child Requests is selected.

  4. In the Next stage field, check that PRE-PROD is selected. Click Next.

    Because Deploy by Default is not enabled, no deploy options are available.

  5. Click Next.

    A summary of the promotion activity and command that will be performed is displayed.

  6. Click Finish.

    Dimensions CM sends an email to the release manager, Rita, notifying her that a promotion has been performed.

  1. In the navigation pane, select the PRE-PROD stage node.

  2. In the content pane verify that the request was promoted successfully from QA to PRE-PROD.

The QA manager actions the request to its final lifecycle state.

Tao closes the request.

  1. In the History tab, select the request.

  2. In the toolbar, click Action. The Action wizard opens.

  3. Check that the To Next State field is set to CLOSED.

  4. Click Finish and click OK.

  5. Log out of the web client.

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).

  1. Log in to the web client as Rita.

  2. Select the Deployment view, and check that only the current stream is displayed.

  3. Select the Pending tab.

  4. In the navigation pane, expand the PRE-PROD stage node and select the LCL_PP_JBRNCHA_AREA03 deployment area.

  5. In the content pane, from the Show list, select Requests.

  6. Select the request, and in the toolbar click Deploy. The Deploy wizard opens.

  7. Check that the option Deploy Child Requests is selected.

  8. Check that the Deploy Stage is set to PRE-PROD.

  9. Click Next.

  10. To deploy the request and child task immediately, check that the option Perform Deployments is set to As Soon As Possible.

  1. In the Areas for Deployment field, check that the LCL_PP_JBRNCHA_AREA03 deployment area is selected.

  2. Click Next.

    A summary of the deployment activity and command that will be performed is displayed.

  3. Click Finish and click Close.

  4. Select the History tab.

  5. Verify that the request and child task were successfully deployed to the PRE-PROD area.

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.

  1. In the History tab, select the request, and in the toolbar click Promote. The Promote wizard opens.

  2. Check that the Promote Child Requests option is selected.

  3. In the Next stage field, check that LIVE is selected.

  4. Click Next.

    Rita has the privilege to deploy at the same time as the promotion but chooses not to. Do not select any deployment areas.

  5. Click Next.

    A summary of the promotion activity and command that will be performed is displayed.

  6. Click Finish.

  1. In the navigation pane select the LIVE stage node.

  2. In the content pane verify that the request was promoted successfully from PRE-PROD to LIVE.

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.

  1. In the History tab, select the request, and in the toolbar click Deploy. The Deploy wizard opens.

  2. Check that the Deploy Child Requests option is selected.

  3. Check that the Deploy Stage is set to LIVE.

  4. Click Next.

  5. To deploy the request and child task immediately, check that the option Perform Deployments is set to As Soon As Possible.

  6. In the Areas for Deployment field, select the LCL_LIVE_JBRNCHA_AREA03 deployment area.

  7. Click Next.

    A summary of the deployment activity and command that will be performed is displayed.

  8. Click Finish and click Close.

The release manager verifies that the deployment operation was successful.

Rita verifies that the deployment operation was successful.

  1. In the navigation pane, expand the LIVE stage node and select the LCL_LIVE_JBRNCHA_AREA03 area.

  2. In the content pane, verify that the request and task were successfully deployed to the LIVE area.

The release manager verifies that the executable was deployed.

Rita verifies that the executable was deployed to the LIVE area.

  1. In the My Current Project tab, expand Deployment Areas > LIVE Stage > LCL_LIVE_JBRNCHA_AREA03

  2. Select the Qlarius Underwriter folder.

  3. In the content pane, verify that LifeQuote.jar was deployed.

End of scenario

Back to top

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

Back to top