The scenarios in this chapter describe the recommended methods for using Dimensions CM to manage deployment. You can run these scenarios in Dimensions CM by following the procedures that follow. All scenarios are performed in the web client.
Qlarius is 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.
Development of the software takes place in London. System integration, QA, and pre-production testing are performed on a simple setup with one machine that hosts 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 are hosting the web application on Linux servers.
These are the company employees that you will meet in the scenarios:
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 web sites. 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.
Qlarius Health Insurance is using the cm_typical process model.
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 (Pre-Production) |
Pre-Production is where the release team runs pre-production tests in an environment that is identical to the live environment. |
|
LIVE |
Live is where the deployment areas for the live environments are located. |
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:
This chapter contains the following scenarios:
|
Scenario Title |
Scenario Description |
|
Changes are required to the corporate web site of Qlarius Health Insurance. A request is deployed to modify the web site. |
|
|
Changes are required to the Qlarius web application. Multiple requests are deployed to a single deployment area at each stage. |
|
|
Changes are required to the Qlarius web application. Multiple requests are deployed to multiple deployment areas in a specific sequence at each stage. |
|
|
Refactoring changes are deployed to the corporate web site of Qlarius Health Insurance. |
|
|
There is a problem with the corporate web site of Qlarius Health Insurance. The solution is to rollback to the previous version. |
|
|
Scenario 6: Deploying 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. |
|
After an update to the corporate web site of Qlarius Health Insurance a defect is found that prevents the site from being used. The quickest solution is to apply an emergency fix. |
|
|
Changes are required to the Qlarius web application. Action driven deployment is used to deploy multiple requests to a single area at each stage. |