The objective of this scenario is to deploy requests to modify the corporate web site of Qlarius Health Insurance.
The release manager raises an enhancement request.
The development team lead primes a child task from the request.
A web developer makes a modification, delivers it, and relates it to the task.
The team lead promotes and deploys the request and task to the SIT stage and deployment area, and then promotes them to the QA stage.
The QA manager deploys the request and task to the QA deployment area and then promotes them 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.
The following stream is used: QLARIUS:MAINLINE_JAVA_STR
No build is required at any stage as only a text file is changed.
There is a separation of duties between the employees at the following stage transitions:
SIT to QA
QA to PRE-PROD
Deployment is to a single deployment area at each stage. The following deployment areas are used:
Stage |
Deployment area |
Deploy by Default enabled for area? |
---|---|---|
DEV |
LCL_DEV_JMAIN_AREA01 |
Yes |
SIT |
LCL_SIT_JMAIN_AREA01 |
Yes |
QA |
LCL_QA_JMAIN_AREA01 |
No |
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.
Create a work area on your local machine for the user Wendy, for example:
C:\streams\MAINLINE_JAVA_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.
Switch to the stream QLARIUS:MAINLINE_JAVA_STR.
Take a tip baseline of the stream MAINLINE_JAVA_STR.
To deploy the files 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_JMAIN_AREA01 deployment area is selected. If not, select it.
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 step
j a’ to ’h’ for the other stages and their associated deployment areas:
• QA: LCL_QA_JMAIN_AREA01
• PRE-PROD: LCL_PP_JMAIN_AREA01
• LIVE: LCL_LIVE_JMAIN_AREA01
Log out of the web client.
Action |
Procedure |
The release manager raises an enhancement request |
A change is required to the corporate web site of Qlarius Health Insurance. Rita, the release manager, raises an enhancement request 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 request 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 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 Action wizard appears. The request is removed from Rita’s request inbox. |
The development team lead primes a child task from the request |
Ted reads the email, views the request in his Request inbox, and does some design work to see what part of the web site is affected. He then primes a child task from the 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 child task to a web developer |
Ted delegates the child task to a web developer, Wendy.
The Delegate wizard appears. 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 Action wizard appears. The child task is removed from Ted’s request inbox. |
The web developer updates their work area from the stream |
Wendy reads the email and checks her Request inbox. She does some research and identifies the file that needs to be modified, main.css. Wendy updates her work area from the stream.
The Update from Stream wizard appears. 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 modification to the stream and relates it to the child task.
The Deliver to Stream wizard appears. The Select Request dialog box appears. |
The developer verifies that the item was automatically deployed to the DEV area |
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.
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. |
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.
The Delegate wizard appears. 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.
The Action wizard appears. The task is removed from Wendy’s Request inbox. |
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 Action wizard appears. 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 child task to the SIT stage and its associated deployment area. Deploy by default is enabled for the SIT area.
The Promote wizard appears. A summary of the promotion and deployment activities and command that will be performed is displayed. |
The team lead verifies that the promotion and deployment were successful |
Ted verifies that the promotion and deployment operations were executed successfully.
|
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.
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. |
The team lead actions the request to its next state |
Ted actions the request to its next lifecycle state, IN TEST, so that the QA team can perform testing.
The Action wizard appears. Dimensions CM sends an email to Tao, the QA manager, notifying her that a task has been added to her Request inbox |
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.
The Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
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.
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. |
The QA manager actions the request to its final lifecycle state |
Tao closes the request.
The Action wizard appears. |
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.
The Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
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.
The Promote wizard appears. Rita has the privilege to deploy at the same time as the promotion but chooses not to select any deployment areas. A summary of the promotion activity and command that will be performed is displayed. |
The release manager deploys the request to the LIVE deployment area |
Let’s assume that it is now the regular maintenance period when the LIVE deployment area is offline. Rita checks to see what requests are ready to be deployed to the LIVE deployment area.
The Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
The release manager verifies that the deployment operation was successful |
Rita verifies that the deployment operation was successful.
|
The release manager verifies that the correct item revision was deployed |
Rita verifies that the correct item revision was deployed to the LIVE area.
|
End of scenario |
The tables below list the promotion and deployment privileges required by the users in the above 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 area is a deploy by default area 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 |