The objective of this scenario is to deploy refactoring changes to the corporate web site of Qlarius Health Insurance.
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.
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 for 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.
Create a work area on your local machine for the user Wendy, for example:
C:\streams\JAVA_BRANCHA_STR\wendy
Log into 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 as follows:
a Select the baseline and on the toolbar click Promote.
b In the Next stage field check that SIT is selected.
c Click Next.
d To deploy now, check that the option Perform deployments is set to ’as soon as possible’.
e In the Areas(s) for deployment field check that the LCL_SIT_JBRNCHA_AREA03 deployment area is selected.
f Click Next.
g A summary of the promotion and deployment activities and command that will be performed is displayed.
h Click Finish.
i Repeat steps ’a’ to ’h’ 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.
Action |
Procedure |
The release manager raises enhancement requests |
Refactoring changes are required to the corporate web site of Qlarius Health Insurance. Rita, the release manage, raises two enhancement requests to manage the change:
The New Request dialog box appears. 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 requests to the development team lead, Ted, whose team is responsible for maintaining the web site.
The Delegate wizard appears. 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 Action multiple requests dialog box appears. The requests are removed from Rita’s request inbox. |
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 Prime Request dialog box appears. 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 tasks to a web developer |
Ted delegates both tasks to a web developer, Wendy.
The Delegate wizard appears. 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 Action multiple requests dialog box appears. The tasks are removed from Ted’s request inbox. |
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 Update from Stream dialog box appears. |
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 Deliver to Stream dialog box appears. The following changes types should be selected: The Select Request wizard appears. The refactoring changes are delivered to Dimensions CM. |
The web developer verifies that the refactoring changes were deployed |
Deploy by default 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.
a In the navigation pane click the filter button in the top right corner. b Select Show Current Stream. The Event Result column should display Succeeded. In the navigation pane verify that there is a folder called resources. |
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 Deliver to Stream dialog box appears. The Select Request wizard appears. Make a note of the latest revision of main.css. |
The web developer verifies that the modification was deployed |
Wendy checks that deployment was successful.
The Event Result column should display Succeeded. |
The web developer delegates the tasks to the team lead for peer review |
Wendy delegates the tasks to Ted for peer review.
The Delegate wizard appears. 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 Action wizard appears. The task is removed from Wendy’s Request inbox. |
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 Action wizard appears. The child tasks are removed from Ted’s Request inbox. |
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 Promote wizard appears. Note: If both areas are selected, deselect SIT LCL_SIT_JBRNCHA_AREA01. A summary of the promotion and deployment activities and command that will be performed is displayed. |
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.
In the navigation pane verify that there is a folder called resources. |
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 Promote wizard appears. Deploy by Default is not enabled so no deploy options are available. A summary of the promotion activity and command that will be performed is displayed. Dimensions CM sends an email to the QA manager, Tao, notifying her that a promotion has been performed. |
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 web site.
The Action wizard appears. Note: The request is removed from Ted’s Request inbox. |
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 Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
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.
In the navigation pane verify that there is a folder called resources. |
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 Action wizard appears. Note: The request are removed from Tao’s request inbox. |
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 Promote wizard appears. Deploy by Default is not enabled so no deploy options are available. A summary of the promotion activity and command that will be performed is displayed. Dimensions CM sends an email to Rita, the release manager, notifying her that a promotion has been performed. |
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 Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
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.
In the navigation pane verify that there is a folder called resources. |
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. Deploy by Default is not enabled so the requests and tasks cannot be automatically deployed to the PRE-PROD deployment area.
The Promote wizard appears. Rita has the privilege to deploy at the same time as the promotion but chooses not. Do not select any deployment areas. A summary of the promotion activity and command that will be performed is displayed. |
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 to see 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 Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
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.
In the navigation pane verify that there is a folder called resources. |
End of scenario |
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 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 |