If you are upgrading from HP Quality Center (QC) 11 or 11.52, you may want to know about new behaviors of the install and configuration process for QC/HP Application Lifecycle Management (ALM) 12.xx. When upgrading from HP QC 11, there is a “new” special project created by the configuration wizard, called the Lab_Project. This is used behind the scenes for an HP QC enterprise license but can be used to direct “server-side” automated tests to be run (without having to have an HP QC client open) when using the HP ALM-level license.
If you are already at version 11.52, this Lab_Project already exists but can sometimes complicate the install of HP QC/HP ALM 12.xx. During the run of configuration wizard, it tries to find and upgrade the Lab_Project and also creates a new/blank one to use, just in case. Obviously, if you have an enterprise license, it does not matter if you use the blank Lab_Project. But, if you have the HP ALM-level license or plan to use this HP ALM instance with HP Performance Center, you need to upgrade the existing Lab_Project.
See the following posts from Eye on Testing regarding this subject:
http://eyeontesting.com/questions/9903/can-someone-please-tell-me-about-the-new-lab-proje.html
http://eyeontesting.com/questions/7392/accidentally-deleted-lab-project-repository-folder.html
We also get many questions about whether to upgrade the qcsiteadmin_db used by HP QC/HP ALM or to create a new one. The basic answer is to weigh what time/effort it would take to recreate your user list—or lightweight directory access protocol (LDAP) settings—and to correctly point to all of your projects again against the effort of making sure all the projects in the “inherited” project list are referred to correctly. Many customers take the path of upgrading this qcsiteadmin_db database/schema, but there are some precautions:
1. The projects will be listed in the Site Projects tab of Site Admin, but will not necessarily be pointing to the correct database and repository locations—this must be remedied prior to upgrading the projects (by Remove/editing the DBID file/and Restoring).
Click here for the Eye on Quality post on this subject.
2. Upgraded LDAP settings may not work and may need to be reset before new a install of HP QC works with LDAP again.
Click here for the Eye on Quality post on this subject.
During install, you will see the usual Server Configuration wizard. You will then be presented with a “Site Administration Database Schema” page. Here, you can choose:
- “Create a New Schema” – Good because it creates everything fresh but does not bring over your users’ information (e.g., passwords, full names, email addresses, etc.) and has a blank project tree/list in Site Admin. User IDs will be recreated as you bring in projects but without any user information and all will have blank passwords.
- “Upgrade a copy of the existing schema” – This is good when you want to bring over all your user information (especially useful if using LDAP). Many customers want to do this. The project tree/list will come over as well, but you must be careful as they will still be looking in the old database location for the data and could corrupt the original projects if not carefully re-pointed to the new database locations.
- “Connect to existing schema/second node” – This is not very useful during an upgrade but is useful if standing up a test server, for instance. The project tree/list will come over, but you must be careful as they will be looking in the old database location for the data and could corrupt the original projects if not carefully re-pointed to the new database locations. Also, your users will have access to these projects if they know the test server URL, so you may want to change the project security appropriately.
In this article, we will be dealing with “Upgrading a copy of an existing schema,” assuming that you have already migrated your original qcsiteadmin_db from the old HP QC server’s database.
1. Choose: “Upgrade a copy of the existing schema”
Make sure the schema name is the same as the one you restored into SQL-server (or Oracle) earlier. If you are using SQL-authentication (td user) or Oracle and have overridden the default schema password, make sure to type in the override password here for “Schema password.”
2. Provide a unique new name for the resulting copied and upgraded qcsiteadmin_db database. Here we’ve used “qcsiteadmin_db1220” to indicate the intended HP QC version.
You will be presented with a pop-up about upgrading Lab Management (Lab_Project “project”). If you were using this as part of HP Performance Center or HP ALM 11.5x, you need to also migrate that database (called “default_lab_project_db” or similar in the old database server [get the one referred to in the Projects table of your migrated qcsiteadmin_db]) as you did with qcsiteadmin_db, before you continue.
If you are not using HP ALM-level license, HP Performance Center, or don’t know if you were using it, you can allow HP QC to create a new Lab_Project; however, if it sees one migrated, it will try to upgrade the one referred to in the Projects table of your migrated qcsiteadmin_db.
3. Provide the Security Passphrases – These must be the same as they were on the old HP QC server.
Next, you will see a page regarding security and specifying the confidential security and data passphrases. If you are upgrading qcsiteadmin_db, these must be the same phrases that were used on the old HP QC 11 – 11.52 server. If you do not know them, you can either pull them forward (still encrypted because HP QC will not reveal them to you) or start with a new/blank qcsiteadmin_db (see HP ALM 12.xx install guide section on “Recovering a Lost Confidential Data Passphrase”).
If you do not have a migrated Lab Management (Lab_Project “project”), you will see a dialog about creating a new empty Lab Management project—allow it to do this.
4. Continue through the wizard as you did before on your old server and deploy/start HP ALM/HP QC.
5. Review the migrated/inherited project tree and user list seen in Site Administration
Notice that the HP QC/HP ALM 12.20 server now has the same project tree/user list.
Remember, we are not completely done yet! These projects are still pointing to the old database location and possibly a wrong repository location. The best practice now is to perform a right-click remove, then edit the DBID.xml file in the project repository to point to the new database location and repository (and possibly change the password string). Then, restore each project. You can then continue with a right-click/Maintain/Verify, then Repair and Upgrade each project.