Scenario 4: Deploy refactoring changes
This scenario demonstrates how to deploy refactoring changes to the corporate website of Qlarius Health Insurance.
Note: To run this scenario, first set up the environment, as described in Prerequisites.
Scenario overview
-
The release manager raises enhancement requests.
-
The development team lead primes a child task from each request.
-
A web developer makes the refactoring changes, delivers the modifications, and relates them to the tasks.
-
The team lead promotes and deploys the requests and tasks to the SIT stage and deployment area, and then promotes them to the QA stage.
-
The QA manager deploys the requests and tasks to the QA deployment area and then promotes them to the PRE-PROD stage.
-
The release manager deploys the requests and tasks to the PRE-PROD deployment area and then promotes and deploys them to the LIVE stage and production environments.
Scenario information
-
The following scenario is used: QLARIUS:JAVA_BRANCHA_STR
-
No builds are required as only a text file is modified.
-
There is a division of responsibilities between the employees at the following stage transitions:
-
SIT to QA
-
QA to PRE-PROD
-
-
This scenario uses the following web application deployment areas:
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
-
Create a work area on your local machine for the user Wendy, for example:
C:\streams\JAVA_BRANCHA_STR\wendy
-
Log in to the web client as a user that has the privileges to promote and deploy baselines to any stage and area, for example, the tool administrator, typically dmsys.
-
Take a tip baseline of the stream JAVA_BRANCHA_STR.
-
To deploy the files in the stream to all deployment areas, promote and deploy the baseline:
-
Select the baseline, and click Promote on the toolbar.
-
In the Promote dialog box, check that SIT is selected for the Next Stage, and click Next.
-
To deploy immediately, check that the Perform Deployments option is set to As Soon As Possible.
-
In the Areas for Deployment field, check that the LCL_SIT_JBRNCHA_AREA03 deployment area is selected. Click Next.
-
Review the summary of the promotion and deployment activity and command, and click Finish.
-
-
Repeat the earlier step for the other stages and deployment areas:
QA LCL_QA_JBRNCHA_AREA03 PRE-PROD LCL_PRE-PROD_JBRNCHA_AREA03 LIVE LCL_LIVE_JBRNCHA_AREA03 -
Log out of the web client.
Run this scenario
The following table describes the tasks performed in this scenario.
Action | Procedure |
---|---|
The release manager raises enhancement requests. |
Refactoring changes are required to the corporate website of Qlarius Health Insurance. Rita, the release manage, raises two enhancement requests to manage the change:
|
The release manager delegates the request to the team lead. |
Rita delegates the requests 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 requests have been added to his Request inbox. |
The release manager actions the requests to their next state. |
Rita actions the requests to their next state, UNDER WORK.
|
The development team lead primes a child task from each request. |
Ted reads the email, views the request in his Request inbox, and primes a separate child task from each request.
|
The development team lead delegates the tasks to a web developer. |
Ted delegates both tasks to a web developer, Wendy.
The wizard closes automatically. Dimensions CM sends an email to Wendy notifying her that requests have been added to her Request inbox. |
The development team lead actions the tasks to their next state. |
Ted actions the tasks to their next state, UNDER WORK.
|
The web developer updates her local work area. |
Wendy, the web developer, reads the emails and checks her Request inbox. She updates her local work area from the website folder.
|
The web developer makes some refactoring changes. |
In Wendy’s local work area do the following:
|
The web developer delivers the refactoring changes. |
Wendy delivers the refactoring changes to Dimensions CM and relates them to the first task.
The refactoring changes are delivered to Dimensions CM. |
The web developer verifies that the refactoring changes were deployed. |
The Deploy by Default option is enabled for the DEV web application deployment area, so when Wendy delivered the refactoring changes, they were automatically deployed. She checks that deployment was successful.
|
The web developer modifies the file. |
In Wendy’s local work area modify main.css in the resources directory. 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 modification to Dimensions CM. |
Wendy delivers the modified file to Dimensions CM relates it to the second task.
|
The web developer verifies that the modification was deployed. |
Wendy checks that deployment was successful.
|
The web developer delegates the tasks to the team lead for peer review. |
Wendy delegates the tasks to Ted for peer review.
The wizard closes automatically. Dimensions CM sends an email to Ted notifying him that tasks have been added to his Request inbox. |
The web developer actions the tasks to their next state. |
Wendy actions the tasks to their next state, PEER REVIEW.
|
The team lead does a peer review and actions the tasks to their final state. |
Ted has read his emails, seen the tasks in his Request inbox, and done a peer review of the refactoring changes. He actions both tasks to their final state, CLOSED.
|
The team lead promotes and deploys the requests and tasks to the SIT stage. |
To perform system integration testing, Ted promotes and deploys the requests and tasks to the SIT stage and web application deployment area. Ted promotes both requests in the same operation and lets Dimensions CM automatically deploy the refactoring changes in the correct sequence. Dimensions CM does the following:
Note: If you select multiple requests, or a request with child requests, Dimensions CM automatically resolves the refactoring changes. This applies to both manual and automatic (Deploy by Default) deployments.
|
The team lead verifies that promotion and deployment operations were successful. |
Ted verifies that promotion and deployment operations were successful and that the refactoring changes were deployed to the SIT web application deployment area.
|
Ted performs system integration testing. | |
The team lead promotes the requests and tasks to the QA stage. |
System integration testing has been completed successfully, so Ted promotes the requests and tasks to the QA stage. Deploy by Default is not enabled so the requests and tasks cannot be automatically deployed to the QA deployment area.
|
The team lead actions the requests to their next state. |
Ted actions the requests to their next lifecycle state, IN TEST, so that QA can test the website.
|
The QA manager deploys the requests and tasks to the QA deployment area. |
Tao reads the email and checks her Request inbox. She deploys both requests in the same operation and lets Dimensions CM automatically deploy the refactoring changes in the correct sequence.
|
The QA manger verifies that the refactoring changes were deployed. |
Tao verifies that the refactoring changes were deployed to the QA web application deployment area.
|
The QA team performs their tests. | |
The QA manager actions the requests to their final lifecycle state. |
QA testing has been completed successfully, so Tao closes the enhancement requests.
|
The QA manager promotes the requests and tasks to the PRE-PROD stage. |
QA testing has been completed successfully so Tao promotes the requests and tasks to the PRE-PROD stage. Deploy by Default is not enabled so the requests and tasks cannot be automatically deployed to the PRE-PROD deployment area.
|
The release manager deploys the requests and tasks to the PRE- PROD deployment area. |
Rita reads the email and checks her Request inbox. She deploys both requests in the same operation and lets Dimensions CM automatically deploy the refactoring changes in the correct sequence.
|
The release manger verifies that the refactoring changes were deployed. |
Rita verifies that the refactoring changes were deployed to the PRE-PROD web application deployment area.
|
The release team performs their tests. | |
The release manager promotes the requests and tasks to the LIVE stage. |
Testing has been completed successfully, so Rita promotes the requests and tasks to the LIVE stage. Because Deploy by Default is not enabled, the requests and tasks cannot be automatically deployed to the PRE-PROD deployment area.
|
The release manager deploys the requests and tasks to the LIVE deployment area. |
Let’s assume that it is now the regular maintenance period when the LIVE web application deployment area is offline. Rita checks what requests are ready to be deployed to the LIVE stage. Rita deploys both requests in the same operation and lets Dimensions CM automatically deploy the refactoring changes in the correct sequence.
|
The release manger verifies that the refactoring changes were deployed. |
Rita verifies that the refactoring changes were deployed to the LIVE web application deployment area.
|
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 | Required at these stages |
---|---|---|
REQUEST_PROMOTE_NEXTSTAGE |
Team lead | DEV SIT |
QA Manager | QA | |
Release Manager | PRE-PROD |
Deployment privilege | Privilege owner | Required for these areas |
---|---|---|
The SIT and LIVE 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 |