The objective of this scenario is to deploy requests to modify the Qlarius web application. This scenario is similar to Scenario 2: Deploying Requests to a Single Deployment Area. The main difference is that multiple requests are deployed in a specific sequence to multiple deployment areas.
The release manager raises an enhancement request.
The development team lead primes two child tasks from the request and delegates them to separate developers.
The developers modify items, deliver the modifications and relate them to the tasks, build the tasks, and capture the build outputs in Dimensions CM.
The team lead promotes and deploys the request and tasks in a specific sequence to the SIT stage and deployment areas, and then promotes them to the QA stage.
The QA manager deploys the request and tasks to the QA deployment areas in the same sequence and then promotes them to the PRE-PROD stage.
The release manager deploys the request and tasks to the PRE-PROD deployment areas in the same sequence, and then promotes and deploys them to the LIVE stage and production environments.
The following stream is used: QLARIUS:JAVA_BRANCHA_STR
There is a separation of duties between the employees at the following stage transitions:
SIT to QA
QA to PRE-PROD
A build is only required at the DEV stage.
Deployment is to multiple areas at each stage. The following deployment areas are used:
Stage |
Deployment area |
Deploy by Default enabled on area? |
Server type |
Location |
---|---|---|---|---|
DEV |
LCL_DEV_JBRNCHA_AREA01 |
Yes |
RDBMS |
London |
LCL_DEV_JBRNCHA_AREA03 |
Yes |
Web application |
London |
|
SIT |
LCL_SIT_JBRNCHA_AREA01 |
Yes |
RDBMS |
London |
LCL_SIT_JBRNCHA_AREA03 |
Yes |
Web application |
London |
|
QA |
LCL_QA_JBRNCHA_AREA01 |
No |
RDBMS |
London |
LCL_QA_JBRNCHA_AREA03 |
No |
Web application |
London |
|
PRE-PROD |
LCL_PP_JBRNCHA_AREA01 |
No |
RDBMS |
London |
LCL_PP_JBRNCHA_AREA03 |
No |
Web application |
London |
|
LIVE |
LCL_LIVE_JBRNCHA_AREA01 |
No |
RDBMS |
London |
LCL_LIVE_JBRNCHA_AREA03 |
No |
Web application |
London |
|
LCL_LIVE_JBRNCHA_AREA04 |
No |
RDBMS |
New York |
|
LCL_LIVE_JBRNCHA_AREA05 |
No |
Web application |
New York |
The deployment sequence to these areas is important as the database schema must be updated before the web application code that uses it:
During deployment to the RDBMS areas post deployment scripts run to remotely shutdown the application servers and execute the SQL script that has been deployed to update the database schema. The update to the database is more likely to go wrong and is harder to fix than the file movement. Therefore the database is updated first so that if anything goes wrong there is less work to restore.
After deployment to the RDBMS server has been completed successfully, deployment continues to the web application server area. The scripts in the web application server area then re-start the servers.
Only content relevant to the specific areas is deployed, for example, the Linux RDBMS server area receives the SQL script files and the Linux web application server area receives the Jar files.
For a list of the promotion and deployment privileges required by the users see Scenario Privileges.
Create work areas on your local machine for the users Dinesh and Dawn, for example:
C:\streams\JAVA_BRANCHA_STR\dinesh
C:\streams\JAVA_BRANCHA_STR\dawn
Running this Scenario
Action |
Procedure |
The release manager raises an enhancement request |
Changes are required to the Qlarius web application. 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 Qlarius.
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 two child tasks from the request |
Ted reads the email, views the request in his Request inbox, and does some design work to see what parts of the application are affected. He primes two child tasks 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 tasks to separate developers |
Ted delegates the first child task that he primed, Implement support for Qlarius iPhone app (Java), to Dinesh and the second child task, Implement support for Qlarius iPhone app (sql), to Dawn. Both are developers in his team.
The Delegate wizard appears. The wizard closes automatically. Dimensions CM sends an email to Dinesh notifying him that a task has been added to his 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 first developer updates their work area from the stream |
Dinesh reads the email and checks his Request inbox. He does some research, identifies the item that needs to be modified, Autoquote.java, and updates his work area.
The Update from Stream wizard appears. Dinesh’s work area is updated. |
The developer modifies the item |
In Dinesh’s local work area edit Autoquote.java, which is located in this folder:
For the purpose of this scenario make a minor edit, for example, add a comment to the top of the item. |
The developer delivers the item and relates it to the task |
Dinesh delivers the modified item to Dimensions CM and relates it to the task that is delegated to him.
The Deliver to Stream wizard appears. The Select Request wizard appears. |
The developer verifies that the item was automatically deployed to the DEV areas |
Deploy by default is enabled for the DEV area so when Dinesh delivered the item it was automatically deployed. He 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 developer builds the task and captures the outputs |
Dinesh builds the child task in the DEV web application deployment area and captures the build outputs in Dimensions CM against the task that is delegated to him.
The Run Build wizard appears. The Select Request wizard appears. a From the Product name list select QLARIUS. b From the Type name list select TASK. c Click Next. d Select the child task that is delegated to Dinesh. e Click Finish. A summary of the build command that will be executed is displayed. |
The developer verifies that the build was successful and that the outputs were captured in Dimensions CM and deployed |
Dinesh verifies that the build was successful and that the outputs were captured in Dimensions CM against the task and deployed to the DEV web application deployment area.
The Open Request dialog box appears. A list of all the build outputs that were captured in Dimensions CM against the task is displayed. |
The developer delegates the task to the team lead for peer review |
Dinesh delegates the task to Ted 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 developer actions the task to its next state |
Dinesh actions the task that is delegated to him to its next state, PEER REVIEW.
The Action wizard appears. The task is removed from Dinesh’s request inbox. |
Log into the web client as Dawn and perform the following, similar, actions:
Note: Dawn builds and tests the sql file locally. |
|
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, done a peer review of the items that Dinesh and Dawn modified, and is satisfied with the changes that they made. He actions the 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 request and tasks to the SIT stage and RDBMS server area |
To perform system integration testing, Ted promotes and deploys the request and the child tasks to the SIT stage and deployment areas in the following order:
Deploy by default is enabled for the SIT areas. A build is not required at the SIT stage so the team lead uses an area filter to only deploy the items that are required for testing at SIT (the executables).
The Promote wizard appears. Note: If both areas are selected, deselect SIT LCL_SIT_JBRNCHA_AREA03. 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 sqlemail file was deployed to the SIT RDBMS deployment area.
|
The team lead deploys the request and tasks to the SIT web application server area |
Deployment to the RDBMS server area has been completed successfully so Ted now deploys the request and tasks to the SIT web application server area.
The Deploy wizard appears. A summary of the deployment activity 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 .jar file was deployed to the SIT web application deployment area.
|
Ted performs system integration testing. |
|
The team lead promotes the request and tasks to the QA stage |
System integration testing has been completed successfully so Ted promotes the request and tasks 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. Dimensions CM sends an email to the QA manager, Tao, notifying her that a promotion has been performed. |
The team lead actions the request to its next state |
Ted actions the request to its next lifecycle state, IN TEST, so that QA can test the application.
The Action wizard appears. Note: The task is removed from Ted’s request inbox. |
The QA manager deploys the request and tasks to the QA deployment areas |
Tao reads the email, checks her Request inbox, and deploys the request and tasks to the QA deployment areas in the same sequence:
A build is not required at the QA stage so the QA manager uses an area filter to only deploy the items that are required for testing at QA (the executables).
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 actions the request to its final lifecycle state. |
QA testing has been completed successfully so Tao closes the enhancement request.
The Action wizard appears. Note: The request is removed from Tao’s request inbox. |
The QA manager promotes the request and tasks to the PRE-PROD stage |
Tao promotes the request and tasks to the PRE-PROD stage. Deploy by Default is not enabled so the request 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 the release manager, Rita, notifying her that a promotion has been performed. |
The release manager deploys the request and tasks to the PRE-PROD deployment areas |
Rita, the release manager, reads the email and checks the Pending tab for the PRE-PROD stage on the Deployment view. Rita sees that the request and tasks are ready to be deployed to PRE-PROD. The deployment sequence is the same as in the previous stages. A build is not required at the PRE-PROD stage so the release manager uses an area filter to only deploy the items that are required at PRE-PROD (the executables).
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 tasks to the LIVE stage |
Testing has been completed so Rita promotes the request and tasks 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. Do not select any deployment areas. A summary of the promotion activity and command that will be performed is displayed. |
The request and tasks are now ready to be deployed to the company’s live production environments in London and New York. Deployment normally takes place during the regular maintenance period when the areas are offline. Rita does the following:
Note: Rita deploys to the LIVE deployment areas in the same sequence as in the previous stages. |
|
The release manager schedules a deployment to the live production environment in New York |
Rita schedules the deployment of the request and tasks to the live production environment in New York at midnight local time.
The Deploy wizard appears. Note: You can also deploy the request from the History tab. Tip: To test this scenario, schedule the deployment to execute soon, for example, in 15 minutes. |
The release manager deploys the request and the tasks to the LIVE RDBMS deployment area in London |
Let’s assume that it is now midnight in London and the local live production environments are offline. Rita checks to see what requests are ready to be deployed to the LIVE stage. She uses an area filter to only deploy the executables.
The Deploy wizard appears. |
The release manager verifies that deployment to the RDBMS area was successful |
Rita verifies that deployment operation was successful and that the sql file was deployed to the LIVE RDBMS deployment area in London.
|
The release manager deploys the request and tasks to the LIVE web application deployment area in London |
The deployment to the RDBMS area was successful so Rita can now deploy the request and tasks to the LIVE web application deployment area in London.
The Deploy wizard appears. |
The release manager verifies that deployment to the web application area was successful |
Rita verifies that deployment operation was successful and that the jar file was deployed to the LIVE RDBMS deployment area in London.
|
Rita emails the New York office to advise them that a deployment has been scheduled for midnight local time and that the deployment in London was successful. Rita goes to sleep and in the morning verifies that the deployment to the production environment in New York was successful. The enhancement to the Qlarius web application is now live across all production environments. |
|
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 DEV area is a deploy by default area and no deployment privileges are required. |
||
REQUEST_DEPLOY ITEM_DEPLOY |
Team Lead |
LCL_SIT_JBRNCHA_AREA01 LCL_SIT_JBRNCHA_AREA03 |
QA Manager |
LCL_QA_JBRNCHA_AREA01 LCL_QA_JBRNCHA_AREA03 |
|
Release Manager |
LCL_PP_JBRNCHA_AREA01 LCL_PP_JBRNCHA_AREA03 LCL_LIVE_JBRNCHA_AREA01 LCL_LIVE_JBRNCHA_AREA03 LCL_LIVE_JBRNCHA_AREA04 LCL_LIVE_JBRNCHA_AREA05 |