Share this page
Deployment scenarios
The scenarios in this section describe the recommended methods for using Dimensions CM to manage deployment. Run these scenarios in the Dimensions CM web client.
About the company
The scenarios use Qlarius, a web-based insurance application developed by Qlarius Health Insurance. Qlarius is built on the J2EE technology stack comprising of a browser-based user interface and a J2EE middle tier consisting of servlets. Qlarius uses EJB technology to talk to a data model that uses an RDBMS.
The software is developed in London. System integration, QA, and preproduction testing run on a simple setup with one machine for the application server and another for the RDBMS. When the application goes live, it is deployed to sites in London and New York. At each of these sites, there is a farm of application server machines and a separate machine hosting the RDBMS. All the sites use Linux servers for the web application.
About the company employees
These are the Qlarius employees you meet in the scenarios:
| Employee | Description |
|---|---|
| Development Team Lead, Ted | Ted is the development team leader, responsible for doing design work, team leadership, tracking progress on development work, and managing the development from a technical perspective. |
| Developer, Dinesh | Dinesh is the Database administrator (DBA) responsible for schema design and making sure software built performs well and is making best use of the RDBMS. Dinesh is a part of Ted’s team and takes technical direction from him. |
| Developer, Dawn | Dawn is a senior software engineer working mostly on the business logic tier of applications. Dawn is a senior member of Ted’s team and often gets the most difficult and challenging technical issues to resolve. |
| Graphic Designer, Gill | Gill is a graphic designer who is responsible for the look and feel of Qlarius. Gill works in Ted’s team as she needs to liaise closely with the developers. |
| Web developer, Wendy | Wendy is a web developer who is responsible for maintaining and updating the company’s websites. Wendy also works in Ted’s team. |
| QA Manager, Tao | Tao is the QA manager responsible for making sure the applications built are fully tested and of a high quality before they are promoted to production. Tao has a team of testers who she leads, and plans and tracks their work. |
| QA Test Engineer, Tony | Tony is a QA engineer responsible for writing test plans, automated tests, running tests, and logging test results. Tim reports to Tao. |
| Release Manager, Rita | Rita is a release manager, her primary role is to ensure smooth delivery of new versions or patches to applications into their live production environment. If production goes down or there is an issue Rita is responsible for fixing it. |
| Release Build Engineer, Bobby | Bobby is a release build engineer responsible for managing the build automation process on-demand by running a script on the command line. Bobby saves the history of builds and releases so that he can investigate any issues that occur. Bobby is a part of Rita’s team and takes technical direction from her. |
| Release Engineer, Tim | Tim is a release test engineer responsible for uncovering any defects, which he reports to the release manager, who then makes the decision to proceed with a release. Tim’s primary role is to improve and stabilize the production and to avoid, or minimize, issues that cause defects. |
Note: Ask your administrator for the user IDs and passwords of these users.
Process model
Qlarius Health Insurance is using the cm_typical process model.
The Global Stage Lifecycle
The Global Stage Lifecycle (GSL) is the base database lifecycle that items follow through the deployment process. The cm_typical process model has the following GSL with five stages from development (DEV) to production (LIVE):
| Stage | Description |
|---|---|
| DEV (Development) | Development is the initial stage where code is developed. |
| SIT (System Integration Test) | System Integration Test is where fixes and enhancements that have been coded, built, and tested by individual developers are brought together so that the whole system can be built and go through formal development testing. |
| QA (Quality Assurance) | Quality Assurance is where the QA team tests the system to ensure it is ready for the live environment. |
| PRE-PROD (Preproduction) | Preproduction is where the release team runs preproduction tests in an environment identical to the live environment. |
| LIVE | Live is where the deployment areas for the live environments are located. |
The Request Lifecycles
Qlarius Health Insurance uses the following lifecycle for enhancement and defect requests:
At the Under Work state, each request can be broken down into one or more child tasks, which have a different lifecycle:
Scenarios
This following table provides a list of deployment scenarios.
| Scenario | Description |
|---|---|
| Scenario 1: Basic request deployment | Changes are required to the corporate website of Qlarius Health Insurance. A Dimensions CM request is deployed to modify the website. |
| Scenario 2: Deploy requests to a single deployment area | Changes are required to the Qlarius web application. Multiple Dimensions CM requests are deployed to a single deployment area at each stage. |
| Scenario 3: Deploy requests to multiple deployment areas | Changes are required to the Qlarius web application. Multiple Dimensions CM requests are deployed to multiple deployment areas in a specific sequence at each stage. |
| Scenario 4: Deploy refactoring changes | Refactoring changes are deployed to the corporate website of Qlarius Health Insurance. |
| Scenario 5: Roll back a deployment | There is a problem with the corporate website of Qlarius Health Insurance. The solution is to rollback to the previous version. |
| Scenario 6: Deploy a fix forward solution using a request | A defect at the QA stage is preventing testing on the Qlarius web application. The solution is to prepare a fix and deploy if forward over the part of the application that is not working. |
| Scenario 7: Deploy an emergency fix | After an update to the corporate website of Qlarius Health Insurance a defect is found that prevents the site from being used. The quickest solution is to apply an emergency fix. |
| Scenario 8: Deploy requests by actioning | Changes are required to the Qlarius web application. Action driven deployment is used to deploy multiple requests to a single area at each stage. |
Next steps:
