Scenario 7: Deploy an emergency fix

This scenario demonstrates how to apply a quick solution by making an emergency fix.

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

Scenario overview

After an update to the Qlarius Health Insurance corporate website, a defect is found that prevents the site from being used by the customers. Rolling back to the previous version is not a solution, as changes were introduced that the company does not want to lose.

  • The release manager raises a Dimensions CM change request to track the defect.

  • The development team lead primes a task from the request.

  • A web developer fixes and delivers the defect, and relates it to the task.

  • The team lead promotes the request and task 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:MAINLINE_JAVA_STR.

  • There is a division of responsibilities between the employees at the following stage transitions:

    • SIT to QA

    • QA to PRE-PROD

  • No build is required at any stage as only a text file is changed.

  • This scenario uses the following deployment areas:

    Stage Deployment area Deploy by Default enabled on area?
    DEV LCL_DEV_JMAIN_AREA01 Yes
    PRE‑PROD LCL_PP_JMAIN_AREA01 No
    LIVE LCL_LIVE_JMAIN_AREA01 No

For a list of the promotion and deployment privileges required by the users, see Scenario privileges ‌.

Back to top

Scenario prerequisites

Before you start this scenario, complete the following steps:

  1. Log in to the web client as any user.

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

  3. Browse the LIVE web application deployment area: In the My Current Project view, expand Deployment Areas > LIVE Stage > LCL_LIVE_JMAIN_AREA01 > Qlarius Underwriter > website.

  4. In the content pane, make a note of the revision of index.html that is currently deployed in this area.

  5. Log out of the web client.

Back to top

Run this scenario

The following table describes the tasks performed in this scenario.

Action Procedure
Rita, the release manager, investigates the problem and discovers a defect in index.html. Rita decides that the best solution is to deploy an emergency fix.

The release manager raises a change request.

Rita raises a change request to fix and track the defect.

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

  2. Switch to the following stream: QLARIUS:MAINLINE_JAVA_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 a title for the request, for example, Fix index.html,

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

  6. In the Attributes tab, from the Severity/Priority list, select Really Urgent.

  7. Click Submit and click 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 the website.

  1. Select the request, and in 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 in 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 click OK. The request is removed from Rita’s request inbox.

  4. Log out of the web client.

The development team lead primes a task from the request.

Ted reads the email, views the request in his Request inbox, and primes a child task from the request.

  1. Log in to the web client as Ted.

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

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

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

  5. (Optional) Update the detailed description.

  6. Click Submit and click 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 web developer.

Ted delegates the task to a web developer, Wendy.

  1. Select the child task, and in 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 Wendy, and click Add.

The wizard closes automatically. Dimensions CM sends an email to Wendy notifying her that a task has been added to her 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 in 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 click OK. The child task is removed from Ted’s request inbox.

  4. Log out of the web client.

The web developer updates their work area from the stream.

Wendy reads the email, checks her Request inbox, and updates her work area from the stream to make sure she has the latest revision of index.html.

  1. Log in to the web client as Wendy.

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

  3. Check that Wendy’s work area is correct (see Prerequisites at the start of scenario 1).

  4. In the Items tab, in the Dirs tab of the navigation pane, expand Qlarius Underwriter, and select website.

  5. In the toolbar, click Update. The Update from Stream wizard opens.

  6. Click Next.

  7. Click Finish and then Close. Wendy’s work area is updated.

The web developer modifies the item. In Wendy’s local work area on your machine, edit index.html. For the purpose of this scenario make a minor edit, for example, add a comment to the top of the file.

The web developer delivers the item and relates it to the task.

Wendy delivers the modified file to the stream and relates it to the child task.

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

  2. In the toolbar, click Deliver. The Deliver to Stream wizard opens.

  3. Check that the Modifications option is selected.

  4. Click Next.

  5. Verify that index.html is selected and click Next.

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

  7. From the Product Name list, select QLARIUS.

  8. From the Type Name list, select TASK.

  9. Click Next.

  10. Select the task that is delegated to Wendy and click Finish.

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

  12. Make a note of the latest revision of index.html (see the content pane).

The web developer delegates the task to the team lead for peer review.

Wendy delegates the task to Ted, her team lead, for peer review.

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

  2. Select the child task, and in 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 web developer actions the task to its next state.

Wendy actions the task to its next state, PEER REVIEW.

  1. Select the child task, and in 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 Wendy’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 file that Wendy modified, and is satisfied with the changes that she 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 select Action. The Action wizard opens.

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

  5. Click Finish and click OK. The task is removed from Ted’s request inbox.

The team lead promotes the request and task straight to the PRE-PROD stage.

Because this is an emergency fix that is required urgently, Ted promotes the request and task straight from DEV to PRE-PROD, bypassing the intermediate stages (SIT and QA).

The Deploy by Default option is not enabled, so the request and task cannot be automatically deployed to the PRE-PROD deployment area.

  1. Select the request.

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

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

  4. From the Next stage field, select PRE-PROD. Click Next.

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

  5. Review the summary and click Finish.

The team lead verifies that promotion was successful.

Ted verifies that promotion to PRE-PROD was successful.

  1. Select the Deployment view .

  2. To view information only for the current stream, click the filter button at the top right of the navigation pane, and select Show Current Stream.

  3. Select the History tab.

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

  5. In the content pane, verify that the request was promoted successfully from DEV to PRE-PROD.

The team lead delegates the request to a QA engineer.

Ted delegates the request to Tony, a QA engineer, for testing.

  1. In the Requests tab, select the request, and in 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 QA ENGINEER, and click Next.

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

The wizard closes automatically. Dimensions CM sends an email to Tony notifying him that a task has been added to his Request inbox.

The team lead actions the request to its next state.

Ted actions the request to its next lifecycle state, IN TEST, so that the Tony can perform testing.

  1. Select the request, and 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 Fixed index.html.

  5. Click Finish. The task is removed from Ted’s Request inbox.

    Dimensions CM sends an email to Tony notifying him that a task has been added to his Request inbox.

  6. Log out of the web client.

Let’s assume the following:

  • Tony has tested the website to make sure that the latest revision of index.html fixes the problem.

  • Tao, the QA manager, has closed the request.

The release manager deploys the request to the PRE-PROD deployment area.

Rita, the release manager, checks the Pending tab for the PRE-PROD stage on the Deployment view. Rita sees that the request is ready to be deployed to PRE-PROD.

  1. Log in to the web client as Rita.

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

  3. Select the Pending tab.

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

  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 Deploy Child Requests option is selected.

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

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

  10. In the Areas for Deployment field, check that the LCL_PP_JMAIN_AREA01 deployment area is selected. Click Next.

  11. Review the summary.Click Finish and then Close.

  12. Select the History tab.

  13. In the navigation pane, in the PRE-PROD stage node, select the LCL_PP_JMAIN_AREA01 deployment area.

  14. In the content pane, verify that the request and child task were successfully deployed to the PRE-PROD area.

The release manager promotes and deploys the request and task to the LIVE stage and deployment area.

Because this is an emergency fix, Rita immediately promotes and deploys the request and task to the LIVE stage and deployment area.

  1. In the History tab, select 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 LIVE is selected. Click Next.

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

  6. Deploy by Default is not enabled for the LIVE deployment area. But Rita has the privilege to deploy at the same time as the promotion.

    In the Areas for Deployment field, select the LCL_LIVE_JMAIN_AREA01 deployment area. Click Next.

  7. Review the summary and click Finish.

  8. In the navigation pane, select the LIVE stage node.

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

  10. In the navigation pane, select the LCL_LIVE_JMAIN_AREA01 deployment area.

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

The release manager verifies that the emergency fix was deployed.

Rita verifies that the latest revision of index.html was deployed to the LIVE area.

  1. In the My Current Project view, in the navigation pane, expand Deployment Areas > LIVE Stage > LCL_LIVE_JMAIN_AREA01 > Qlarius Underwriter > website.

  2. In the content pane, verify that the latest revision of index.html was deployed. This revision has replaced the one that was deployed at the start of this scenario.

Note: After the emergency deployment is completed, the latest revision of index.html goes through the normal testing procedures. If it passes the tests successfully it remains in the LIVE deployment areas.
End of scenario

Back to top

Scenario privileges ‌

The following tables list the promotion and deployment privileges required by each user in the scenario.

Promotion privilege Privilege owner
REQUEST_PROMOTE_ANYSTAGE
ITEM_PROMOTE_ANYSTAGE
Team lead
Release Manager
Deployment privilege Privilege owner Required for these areas
The DEV and LIVE areas are Deploy by Default areas, and no deployment privileges are required.
REQUEST_DEPLOY
ITEM_DEPLOY
Release Manager LCL_PP_JMAIN_AREA01

Back to top