Quality Center Upgradation Document from 9.

0 to Higher Version

Version: 1.0

Issue date: 10/05/2011

 Copyright 2011 Satyam Computer Services Ltd. All rights reserved.

_________________________________________________________________________________________

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

Table of Contents

1. Introduction ....................................................................................................4 2. Limitations of the New Upgraded Systems......................................................5 3. UpGradation....................................................................................................5 4. Migration process ...........................................................................................7 5. Before the new version implementation - Remove partitioning .......................7 6. Locate and modify tools that access the repository directly ............................8 7. Grant permissions to repository directory .......................................................8 8. Review the project repository folders .............................................................8 9. New implementation requirements .................................................................8 9.1. Repository storage requirements ..............................................................8 9.2. Considerations ..........................................................................................8 9.3. Backup of project DB and repository .........................................................9 10. Prepare rollback procedure ......................................................................9 11. Define sanity tests to be performed after upgrade ....................................9 12. Review post-upgrade checklist .................................................................9 13. PROCESS STEPS......................................................................................11

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

1. Introduction
Quality Centre provides a centralized platform for managing and automating the application lifecycle. It empowers application teams to plan, build and release betterquality applications. QC helps us to Centrally managed and track all application projects Attain real-time visibility into the application lifecycle Centrally manage and consistent workflows and processes Reduce duplication of effort across projects Provide an aggregated, cross-application project view of quality status and defect trends

Facilitate collaboration and communication among internal and external stakeholder groups, across multiple projects.

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

Quality Centre project holds two locations, Project database schema and the projects file system repository. While the database schema contains most of the information about the project, the repository holds different types of files such as attachments, automated test results, workflow scripts etc. The projects file system repository is affected by end user actions such as Adding, removing or modifying attachments Creation or modification and run of automated test scripts Check-out and Check-in attachments and automated scripts and results Pasting entities as attachments, automated scripts and results Creation of baseline Editing of workflow scripts Creation of analysis items

2. Limitations of the New Upgraded Systems

Some operating systems have a limitation on the number of files and folders that can be stored under the same folder Some operating systems have a limitation on path length of a file File duplication, resulting from running automated tests or attaching identical files, issues with backup and restore, large storage space and extensive time, due to the size and amount of files. Quality Center versioning and baseline features, copy assets as is, including their repository assets, causing duplications, which makes the repository hard to maintain and backup, due to its increased size. copying, opening of

Performance issues in repository-related actions, such as attachments etc. might be caused by the size of the repository.

3. UpGradation
The new Optimized Repository is based on an abstraction between the logical file system structure (which is the file system structure) and Physical file system structure (which is the actual structure of the files on the disk). This separation is achieved by the introduction of two new tables in the DB. One represents the logical File Structure and the other the actual File Structure on the disk. This enables us to create a balanced tree structure in the disk as well as save only a single copy of each file meaning that every file that has duplicates in the disk, from now on, will only be saved once on the disk but have multiple references from the logical table.

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

In order to identify duplications, direct access to the file system is strictly forbidden from now on, and not possible to the new cryptic structure of the repository in Advances Tool To upgrade a project, consider the flow

All access to the FS must be done through the Extended Storage interface. Deletions of files only affect the logical table. A scheduled job runs periodically (customizable) and its task is to delete physical files that are no longer used by any logical file.

Version Control checks out permission - Users with only the Viewer group can still
check out Requirements and Business Components. Version Number field in Test Plan module - You can not reposition this field through the workflow code. It will always be the first field in projects with VC enabled. You can reposition the field in the Requirements, Components, and Test Resources modules. Creating a new Test Resource - depending on what order you click on items you may have to click the Submit button twice (or hold it down extra long). When selecting the Resource Type the window loses focus, the first click restores focus, and the second click submits. Deleting more than one Dashboard page in same folder at a time - QC will prompt you about deleting the entire folder even if you don't select the folder or all pages in the folder. If you proceed the folder is actually NOT deleted. Moving Requirements in a VC enabled project - If you move a checked out folder to another folder and then move a second folder to that same folder an error and some minor data corruption occurs. __________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

4. Migration process
The migration is done in two phases. The first is relatively short and is actually part of the upgrade mechanism. Its task is to map the entire FS into the logical table. Once this process is done, the project can be used normally. The second phase is usually longer but runs in the background. At this stage, the files are scanned, digested and moved to their new location if needed, or deleted if a copy already exists. At this stage it is obviously not possible to copy and export projects, to ensure a full and successful migration process. The run time of both phases depends on the number of files and folders on disk, not on the size of the repository. During the second phase, each QC server node will allow concurrent migration of multiple projects. The user can set the priority that this task will have, and determine the amount of resources it uses

Use a lot of resources but finish quicker good for those who have a scheduled downtime for the entire weekend and want to get things done during weekend Use fewer resources and thereby have a low impact on QC users, but cause the entire process to take longer.

Administration page will include a new window which will help QC admins to monitor and track the progress of the migration. This is also the place to be notified on problems during this process. In case of such notifications, you will be able to fix the problem and resume the migration.

5. Before the new version implementation - Remove

partitioning
This is the feature that enabled user to set a different location for the tests folder, resources, and more. This feature is no longer supported and the user must realign the folders before the process begins. Upgrade to higher version will not be possible as long as partitioning is used. To do this, simply update the relevant records in the DATA_CONST table, and move the files back to their original location. Then restart QC. In other words, reverse the steps you took when you started using the partitioning feature.

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

6. Locate and modify tools that access the repository directly

Since direct file access is no longer supported, you must either disable any tools that access the repository directly, or modify them to work. Make sure the local of the DB server, QC server and FS server are aligned Failing to do so may result in missing files. This prerequisite is needed, since Java code running on the QC server scans the FS and must be able to read the file names. The files are then catalogued in the DB. Therefore, the DB must be able to represent the file names, so that they can be located afterwards.

7. Grant permissions to repository directory

The migration process requires full permissions on the project repository directory for the user running the QC service on the QC server machine. Make sure full permissions are assigned before installing the new version.

8. Review the project repository folders

Check the repository root folders for folders that are not related to Quality Center. The migration process migrates all files and folders under the project root folders. The migration will take longer if the root folder includes redundant files that are not related to Quality Center. Also, any unrelated files will be inaccessible after the migration in the new file structure. The migration process changes the structure and location of the scripts folder. Therefore it is recommended to save a copy of the scripts folder before migration.

9. New implementation requirements 9.1. Repository storage requirements

The FS is expected to shrink, both in number of files and folders as well as in volumes on the disk. The ratio may vary dramatically, and best results are expected on projects with large number of files and Folders (Large volumes). The DB, on the other hand, is expected to grow due to the listing of each logical file and its physical entry in the DB.

9.2. Considerations
Both phases of the migration involve scanning the entire FS and reflecting it in the DB. It is, therefore intensive. If all elements (DB, QC and FS) are on the same machine, the __________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

network element is optimized. This is another reason we recommend using different machines for the DB, QC and FS. Note that network quality may affect the process. Best results can be achieved by using different machines on the same network, with wide bandwidth and low latency.

9.3. Backup of project DB and repository

As the new upgrade mechanism and migration now involve, not only the project database schema, but also the project file system repository, it is highly recommended that you backup your project DB schema along with the file system repository directory.

10.

Prepare rollback procedure

Define a list of possible problems that might occur during the upgrade procedure. To be prepared for these problems, create mitigation plans that lower the associated risks and for each risk, create a result plan. If necessary, create a rollback procedure that facilitates working with the existing environment. This is very important when performing mass upgrade. As a precautionary step, back up all projects and site administration schemas before upgrading. Back up only while the project is deactivated and as close as possible to down-time to allow the maximum working period with the project and minimum data loss. Make sure to assign stakeholders to the rollback procedure plan.

11.

Define sanity tests to be performed after upgrade

When the validation of the testing environment is officially completed, define, after considering the testing results, which key areas are affected during the upgrade process. Define these key areas as high risk areas that should be included in sanity tests once the upgrade is completed for each of the projects. In addition, any basic functionality that was used on a frequent basis should also be included as a sanity test for each of the projects.

12.

Review post-upgrade checklist

After the upgrade, check the following: Alert the project contact about the completeness of the project upgrade. Verify that you can connect to the projects in Site Administration. Ask the users to check that they can log in to all ALM projects using their account. Alert your project contact to perform the sanity tests defined earlier. Ask the users to perform their routine operations and report feedback such as response time or the occurrence of errors.

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

 Ask the users to check new features and functionalities within ALM and provide feedback. Check the users' group permissions that may be set by default for new features, and modify them if necessary. Perform a load test on the testing environment to verify that it can handle the intended number of users. If you are using an HP integration or a third-party tool with ALM, validate backward compatibility of the integration and provide feedback.

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

13. PROCESS STEPS

Before migration, deactivate all projects from the Site Administrator 1. Backup the projects databases/schemas and Site administration database/schema (default name qcsiteAdmin_db) from the QC9.x database server 2. Backup the projects repositories from the QC 9.x server. Each project has the location of the repository at the project properties in the Site Administration web site. 3. Restore the project databases/schemas and the Site administrations database/schema at the next level database server (if you are using a new database server) Note: If upgrading QC, theres no need to move projects databases/schemas however is important to take backups. 4. Install higher version of QC, if you are using the same application server you must uninstall QC9.2 or QC10 QC has 2 different databases, the project databases and the site admin database. When migrating, to keep users, user configurations, and site administration parameters you must install using the same database name that was used to restore the project in your DB server. Select Upgrade a copy or Upgrade the existing schema option during installation. 5. Paste/Restore the repositories in the expected repository location in the new installation 6. Restore the projects a) Login Site Administrator and create a new empty project. b) Go to the new empty projects folder repository and make a copy of the dbid.xml file. c) Remove your projects from the Site Administration (Reason: it has connections to the old database server). Do not delete the project because it will remove the project schema from the database server. d) Go to the projects folder and rename the existing dbid.xml file to dbidold.xml e) Paste a copy of the dbid.xml file from the empty new project. f) Edit the dbid.xml to match your project environment description as follow __________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version

PROJECT_NAME : Name of the project, for example: NEW_PROJECT. DB_NAME : Name shown in the database list, for example: NEW_PROJECT_DB PHYSICAL_DIRECTORY : <Drive>:\Program Files\Mercury\Quality Center\ repository\qc\ <Domain_Name>\ <Project_Name_Folder> PROJECT_UID : Keep the same amount of digits and modify the last two values to get a unique ID 7. From the site administrator restore projects using the dbid.xml file edited for all projects. 8. Verify, repair and upgrade projects 1. Right click on it and select Maintain Project 2. Select Verify Project 3. After verification finished, select Repair project 4. After project repair, select Upgrade project Notes After upgrade the project you can not change its repository folder location, the reason of that is that there is a new feature in ver. 10/11 that optimizes the projects repository. Try on a Test server first and then on production Server **

__________________________________________________________________________________________ Quality Center Upgradation from 9.0 to Higher Version