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.
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 .
Scenario prerequisites
Before you start this scenario, complete the following steps:
-
Log in to the web client as any user.
-
Switch to the following stream: QLARIUS:MAINLINE_JAVA_STR.
-
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.
-
In the content pane, make a note of the revision of index.html that is currently deployed in this area.
-
Log out of the web client.
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.
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.
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 task from the request. |
Ted reads the email, views the request in his Request inbox, and primes a child task from the request.
|
The development team lead delegates the task to a web developer. |
Ted delegates the task to a web developer, Wendy.
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.
|
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.
|
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.
|
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.
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.
|
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.
|
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.
|
The team lead verifies that promotion was successful. |
Ted verifies that promotion to PRE-PROD was successful.
|
The team lead delegates the request to a QA engineer. |
Ted delegates the request to Tony, a QA engineer, for testing.
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.
|
Let’s assume the following:
|
|
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.
|
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.
|
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.
|
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 |
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 |