Scenario 5: Rolling Back a Deployment

Scenario Objective

There is a problem with the corporate web site of Qlarius Health Insurance. The objective of the scenario is to rollback to the previous version, create a fix, and then deploy the fix to the live environment.

For example, let’s assume that revision 2 of a file is currently deployed to the LIVE deployment area. The rollback operation redeploys revision 1 to LIVE. The fix creates revision 3, which is promoted and deployed up the GSL to LIVE and replaces revision 1.

Scenario Overview

Scenario Information

Pre-Requisites

  1. To run this scenario you must have successfully completed Scenario 1: Basic Request Deployment.

  2. Log into the web client as any user.

  3. Switch to the stream QLARIUS:MAINLINE_JAVA_STR.

  4. On the Request view select Catalog.

  5. Make a note of the ID of the enhancement request that was raised by Rita in scenario 1 and used to deploy the changes. For the purposes of this scenario we will call this CR_X.

  6. In the Items view, in the navigation pane on the Dirs tab, expand Qlarius Underwriter and select the website folder. In the content pane select the filter All Revisions.

  7. Make a note of the current and previous revisions of main.css.

  8. Log out of the web client.

Running this Scenario

Action

Procedure

Rita, the release manager, investigates the problem with the corporate web site of Qlarius Health Insurance and discovers a small defect in main.css, which is related to CR_X. Rita decides that the best solution is to immediately rollback to the previous version of main.css.

The release manager checks the deployment history

Rita, the release manager, checks the deployment history to see if any requests were deployed to the LIVE deployment area after CR_X.

  1. Log into the Dimensions CM web client as Rita.

  2. Switch to the following stream: QLARIUS:MAINLINE_JAVA_STR

  3. Select the Deployment view.

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

    5. a    In the navigation pane click the filter button in the top right corner.

    b    Select Show Current Stream.

  5. Select the History tab and in the navigation pane select the LIVE stage node.

  6. Expand the LIVE stage node and select the deployment area LCL_LIVE_JMAIN_AREA01.

  7. In the content pane use filters to only display requests that can be rolled back:

    8. a    From the Show list select Requests.

    b    From the Occurred list select the period when you performed scenario 1 (Today, in the last week, etc).

    c     Click the Filter button (located to the left of the Show list).

    d    Select the option Hide if can't roll back.

  8. In the content pane check the history to see if any requests were deployed to the area after CR_X. The content pane should look similar to this:

    rollback.png

  • QLARIUS_CR_X is the parent enhancement request.

  • QLARIUS_TASK_X is the child task that was primed from CR_X.

  • No other requests were deployed after CR_X.

The release manager rolls back the request from the LIVE deployment area

Rita rolls back CR_X from the LIVE deployment area.

  1. On the History tab select the request QLARIUS_CR_X.

  2. On the toolbar click Roll Back.

    3. The Roll Back Area Versions dialog box appears.

  3. To roll back the request immediately, check that the option Perform roll back of area versions is set to ’as soon as possible’.

  4. In the Reason for roll back field enter: Defect in main.css

  5. In the Select area versions for rolling back operations table check that LCL_LIVE_JMAIN_AREA01 is selected.

  6. Click Next.

  7. A summary of the roll back activity and command that will be performed is displayed.

  8. Click Finish.

  9. Unselect Hide if can't roll back.

  10. Check if the roll back succeeded. The content pane should look similar to this:

    rollback2.png

The parent request and child task have been rolled back.

The release manager checks that the previous revision of the item was redeployed

Rita checks that the rollback successfully redeployed the previous revision of main.css to the LIVE deployment area.

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

  2. In the content pane verify that the previous revision of main.css was deployed.

The release manager demotes the request to the PRE-PROD stage.

Rita demotes request CR_X to the PRE-PROD stage to indicate that it is no longer live.

  1. In the Deployment view, on the History tab, select the LCL_LIVE_JMAIN_AREA01 area in the navigation pane.

  2. In the content pane select CR_X and on the toolbar click Demote.

    3. The Demote dialog box appears.

  3. Check that the option Demote child requests is selected.

  4. Check that the To Stage is set to PRE-PROD.

  5. Click Next.

  6. To deploy the requests now, check that the option Perform deployments is set to ’as soon as possible’.

  7. In the Areas(s) for deployment field select the LCL_PP_JMAIN_AREA01 deployment area.

  8. Click Next.

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

  9. Click Finish.

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

  11. In the content pane verify that request CR_X was successfully demoted from LIVE to PRE-PROD. The content pane should look similar to this:
rollback3.png

 

The release manager raises a change request to track the defect

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

  1. In the Request view, on the toolbar click New and select CR.

    2. The New Request dialog box appears.

  2. In the Title field enter a title for the request, for example: Fix main.css.

  3. In the Detailed description field enter a description.

  4. On the Attributes tab, from the Severity/Priority list select Really Urgent.

  5. 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 web site.

  1. Select the request and on the toolbar click Delegate.

    2. The Delegate wizard appears.

  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.

    2. The Action wizard appears.

  2. Check that the To next state field is set to UNDER WORK.

  3. Click Finish and click OK.

    4. 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 primes a child task from the request.

  1. Log into the web client as Ted.

  2. Switch to the following stream: QLARIUS:MAINLINE_JAVA_STR

  3. In the Request view select the Request inbox and then the request that was raised by Rita.

  4. On the toolbar click Prime and select Task.

    5. The Prime Request dialog box appears.

  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 on the toolbar click Delegate.

    2. The Delegate wizard appears.

  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 on the toolbar select Action.

    2. The Action wizard appears.

  2. Check that the To next state field is set to UNDER WORK.

  3. Click Finish and click OK.

    4. 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 version of main.css.

  1. Log into 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 the pre-requisites at the start of scenario 1 on page 513).

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

  5. On the toolbar click Update.

    6. The Update from Stream wizard appears.

  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 main.css. 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 task.

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

  2. On the toolbar click Deliver.

    3. The Deliver to Stream wizard appears.

  3. Check that the Modifications check box is selected.

  4. Click Next.

  5. Verify that main.css is selected and click Next.

  6. In the Relate to request(s) field click Select.

    7. The Select Request dialog box appears.

  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 main.css (see the content pane).

The developer verifies that the item was automatically deployed to the DEV areas

Deploy by default is enabled for the DEV area so when Wendy delivered the item it was automatically deployed. She checks that the item was successfully deployed.

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

  2. Select the History tab and in the navigation pane select the DEV stage node.

  3. In the content pane verify that main.css was successfully deployed to the DEV deployment area LCL_DEV_JMAIN_AREA01.

The Event Result column should display Succeeded.

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

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

  1. In the Requests view select the Request inbox.

  2. Select the child task and on the toolbar click Delegate.

    3. The Delegate wizard appears.

  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 child task to its next state, PEER REVIEW.

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

    2. The Action wizard appears.

  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.

    7. 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 into the web client as Ted.

  2. In the Requests view select the Request inbox.

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

    4. The Action wizard appears.

  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 and deploys the request and task to the SIT stage

To perform system integration testing, Ted promotes and deploys the parent request with the task to the SIT stage and its associated deployment area. Deploy by default is enabled for the SIT area.

  1. Select the request.

  2. On the toolbar click Promote.

    3. The Promote wizard appears.

  3. Check that the option Promote child requests is selected.

  4. In the Next stage field check that SIT is selected.

  5. Click Next.

  6. To deploy now, check that the option Perform deployments is set to ’as soon as possible’.

  7. In the Areas(s) for deployment field check that the LCL_SIT_JMAIN_AREA01 deployment area is selected.

  8. Click Next.

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

  9. Click Finish.

The team lead verifies that the promotion and deployment were successful

Ted verifies that the promotion and deployment operations were executed successfully.

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

  2. Check that the History tab is selected.

  3. In the navigation pane select the SIT stage node.

  4. In the content pane verify that the request was promoted successfully from DEV to SIT. The Event Result column should display Succeeded.

  5. In the navigation pane expand the SIT stage node and select the LCL_SIT_JMAIN_AREA01 deployment area.

  6. In the content pane verify that the request and task were successfully deployed to the SIT deployment 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.

  1. On the History tab select the request.

  2. On the toolbar click Promote.

    3. The Promote wizard appears.

  3. Check that the option Promote child requests is selected.

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

  5. Click Next.

    6. Deploy by Default is not enabled so no deploy options are available.

  6. Click Next.

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

  7. Click Finish.

  8. In the navigation pane select the QA stage node.

  9. 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 parent request to its next lifecycle state, IN TEST, so that the QA team can perform testing.

  1. On the History tab select the request.

  2. On the toolbar click Action.

    3. The Action wizard appears.

  3. In the New State section check that the To next state field is set to IN TEST.

  4. Click Next.

  5. In the Details of solution given field enter: Fixed defect in main.css updated

  6. Click Finish.

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

  7. Log out of the web client.

The QA manager deploys the request and task to the QA deployment area

Tao, the QA manager, reads the email and checks the Pending tab for the QA stage on the Deployment view. Tao sees that the request is ready to be deployed to QA.

  1. Log into the web client as Tao.

  2. Switch to the following stream: QLARIUS:MAINLINE_JAVA_STR

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

  4. Select the Pending tab.

  5. In the navigation pane select the QA stage node.

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

  7. Select the request and on the toolbar click Deploy.

    8. The Deploy wizard appears.

  8. Check that the option Deploy child requests is selected.

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

  10. Click Next.

  11. To deploy the request and child task now, check that the option Perform deployments is set to ’as soon as possible’.

  12. In the Areas(s) for deployment field check that the LCL_QA_JMAIN_AREA01 deployment area is selected.

  13. Click Next.

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

  14. Click Finish.

  15. Select the History tab.

  16. In the navigation pane expand the QA stage node and select the LCL_QA_JMAIN_AREA01 deployment area.

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

The QA team performs their tests.

The QA manager promotes the request and task to the PRE-PROD stage

QA testing has been complete 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. On the History tab select the request.

  2. On the toolbar click Promote.

    3. The Promote wizard appears.

  3. Check that the option Promote child requests is selected.

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

  5. Click Next.

    6. Deploy by Default is not enabled so no deploy options are available.

  6. Click Next.

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

  7. Click Finish.

  8. In the navigation pane select the PRE-PROD stage node.

  9. 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 that is tracking the defect.

  1. On History tab select the request.

  2. On the toolbar click Action.

    3. The Action wizard appears.

  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, 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 into 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 on the toolbar click Deploy.

    7. The Deploy wizard appears.

  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 now, check that the option Perform deployments is set to ’as soon as possible’.

  11. In the Areas(s) for deployment field check that the LCL_PP_JMAIN_AREA01 deployment area is selected.

  12. Click Next.

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

  13. Click Finish and click Close.

  14. Select the History tab.

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

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

The release team performs their tests.

The release manager promotes the request and task to the LIVE stage

Rita promotes the request and task to the LIVE stage. Deploy by Default is not enabled for the LIVE deployment area.

  1. On the History tab, with the PRE-PROD stage node selected in the navigation pane, select the request in the content pane.

  2. On the toolbar click Promote.

    3. The Promote wizard appears.

  3. Check that the option Promote child requests is selected.

  4. In the Next stage field check that LIVE is selected.

  5. Click Next.

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

  6. Click Next.

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

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

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

Let’s assume it is now the regular nightly maintenance period when the LIVE deployment area is offline. Rita deploys the request and task to the LIVE deployment area.

  1. On the Pending tab select the request and on the toolbar click Deploy.

    2. The Deploy wizard appears.

  2. Check that the option Deploy child requests is selected.

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

  4. Click Next.

  5. To deploy the request and child task now, check that the option Perform deployments is set to ’as soon as possible’.

  6. In the Areas(s) for deployment field check that the LCL_LIVE_JMAIN_AREA01 deployment area is selected.

  7. Click Next.

    8. 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. Select the History tab.

  2. In the navigation pane expand the LIVE stage node and select the LCL_LIVE_JMAIN_AREA01 deployment area.

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

Tip: In the content pane you can see the request that was raised to fix the defect and request CR_X, which you rolled back at the start of this scenario.

The release manager verifies that the fix was deployed

Rita verifies that the latest revision of main.css 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 main.css was deployed. This revision has replaced the one that was redeployed by the rollback operation at the start of this scenario.

End of scenario

Scenario Privileges

The tables below list the promotion and deployment privileges required by each user in the 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_JMAIN_AREA01

Release Manager

LCL_PP_JMAIN_AREA01

LCL_LIVE_JMAIN_AREA01

REQUEST_ROLLBACK_ANYSTAGE

ITEM_ROLLBACK_ANYSTAGE

Note: These privileges are only used for rolling back area versions and will change in a future release.

Release Manager

LCL_PP_JMAIN_AREA01

LCL_LIVE_JMAIN_AREA01

REQUEST_DEMOTE_ANYSTAGE

ITEM_DEMOTE_ANYSTAGE

Release Manager

LCL_PP_JMAIN_AREA01

LCL_LIVE_JMAIN_AREA01