Highlighted
Steven Hulse Absent Member.
Absent Member.
5324 views

Gradual Upgrade process for ALM

Hi everyone,

 

Right now I'm feeling like a complete idiot. I've been fighting with our upgrade in our test environment from v10 of QC to v11 ALM. Today, I find the upgrade best practices document and read about the "Gradual Upgrade". If I would have known about this option months ago I think i would still have some of my hair! 🙂 I'm in the process of setting up our test environment and I think this option would work perfect for that.

 

Anyway, the document doesn't really go into much detail or answers some of the questions I have regarding this option. So I'm on a quest to seek the truth! (so to speak)

 

Some of the questions I have (and I hope some of you good folks can answer them for me) are...

 

  1. Do we have to create a new database in order to perform this? (If so thats ok.)
  2. How do we upgrade the projects one at a time? Do we export them from the existing version and then import them in to ALM and perform the upgrade?
  3. The repository, I would like to move that to it's own server but do i need to do anything special in regards to the existing repository?

 

I'm sure I'll have more questions but this should give me a good amount of data to process.

 

Thanks in advance!

Steve

 

0 Likes
41 Replies
Outstanding Contributor.. Venkat457 Outstanding Contributor..
Outstanding Contributor..

Re: Gradual Upgrade process for ALM

Hi Steve,

 

 

 

  1. Do we have to create a new database in order to perform this? (If so thats ok.)

   I assume you already have existing qc projects in 10 and upgrading them to 11

 

   Consideration here would be if you are moving to a brand new DB server or doing it in an existing server

  If totally moving to brand new DB server

 

 Back up existing projects on current server.Take a copy and restore the schemas onto new DB server.If DB server config changes like upping from sql 2000 to 2005 etc,then project schemas need to be tuned accordingly to fit higher level.

 

Make sure you are copying qcsiteadmin_db schema also which is very improtant

 

Once projects restored,you can upgrade them in QC 11 site.

 

For installing QC 11 you can refer to install guide.Choose upgrade existing schema while install and make sure to add new DB server if new in QC site.

 

  1. How do we upgrade the projects one at a time? Do we export them from the existing version and then import them in to ALM and perform the upgrade?

  once the projects has been restored in DB  ,you will need to get the dbid.xml files from each project from QC install location ,make sure to get the siteadmin .xml file also and make sure of the DB server,repository parameters.

Once everything in place you can do restore from qc site by picking each xml and restore under its corresponding domain.

If successfully restored ,then right click on that project and do verify/repair/upgrade.

 

  1. The repository, I would like to move that to it's own server but do i need to do anything special in regards to the existing repository?

If the repository still remains the same,dbid.xml parameters still remain same and since qcsiteadmin schema was copied over repository parameters will automatically apply onto QC11 site.

 

Regards,

Venkat

 

 

Venkat
0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Thanks for the reply Venkat,

 

We will be sticking with out existing database, I wasn't sure how it actually worked as the information I was reading wasn't that clear about this part.

 

Since we are sticking with our existing database, do I still need to do any of the stuff with the schemas and dbid files? We will be creating two new servers (cluster) for the ALM application itself if that helps explain our future set up.

 

Steve

0 Likes
Outstanding Contributor.. Venkat457 Outstanding Contributor..
Outstanding Contributor..

Re: Gradual Upgrade process for ALM

Steve,

 

If you were sticking with your existing DB,you dont need to change params in dbid's.

 

While installing QC ALM you need to point your existing DB server name and qcsiteadmin_DB.

 

After installation go and restore projects in QC ALM site and then do verify-->repair-->upgrade so the schemas gets upgraded to ALM level.

 

Also refer to attached doc if it can be of help to you.

 

Since your's will be clustered setup install qc on both nodes as well use same DB,repository parameters while installing on both nodes.

 

Regards,

Venkat

 

Venkat
0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Ok, that makes sense.

 

Although I do have one more area I'm a little fuzzy on still. Do I still need to export the projects from v10 and then import them into v11 and then run the V&R?

 

Thank you in advance for your suggestions and help. I'm trying to get a test instance up as well and thats becoming a real nightmare to work with in the approach I was taking which was causing me some confusion about the actual production upgrade.

0 Likes
Outstanding Contributor.. Venkat457 Outstanding Contributor..
Outstanding Contributor..

Re: Gradual Upgrade process for ALM

Please be advised upgrade process doesn't need the export and import process.

 

You can do below.

 

  • Take the backup of project db before you do upgrade.
  • Get that project dbid.xml file
  • Once the ALM is installed and when you login to ALM qc site.click on domain and right click to select option restore ,it will ask you to point dbid.make sure all paramters are correct.If so then point and restore.
  • Once done do verify ,repair and go for upgrade which upgrades the schema to ALM
Venkat
0 Likes
Established Member.. William Schmitt
Established Member..

Re: Gradual Upgrade process for ALM

Something that was not mentioned is that the gradual upgrade requires that you have two servers, either an existing server and a new server, or two existing nodes.  Basically you upgrade one server to v11 while keeping the other server on v10.  Both servers can point to the same database.  You then upgrade each project schema one at a time.  Users can still use v10 projects that haven't been upgraded, while also using upgraded v11 projects.  All project schemas are visible from both servers, but the v10 projects must be upgraded using the upgrade tool in site admin.

 

Upgrading a single server cannot be gradual, as you must uninstall the old QC and install the new QC, then upgrade all projects. 

 

In either case you sho8uld upgrade a copy of the existing site admin schema.

 

0 Likes
Outstanding Contributor.. Venkat457 Outstanding Contributor..
Outstanding Contributor..

Re: Gradual Upgrade process for ALM

Thanks William for raising the point.User questions seems to be more from a DB perspective to me rather than appserver end and Yes we cannot do a gradual upgrade (install ) of QC on the same app server until the previous one is uninstalled.I assume this was listed clearly in the document attached earlier.

Venkat
0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Yep, my design will be two new ALM servers, one Database server (the existing one) and a seperate server for the repository.

 

Originally my plan was to upgrade the existing server (mostly due to budget constraints) but that has been resolved and I am now able to have seperate servers now.

 

Currently I am in the process of setting up a seperate test/training system for ALM 11 and getting a clone (we use Oracle) of our database and it to work together has been a real chllenge. I feel our production upgrade will go quite smoothly compared to getting this test/training instance up and running.

 

I think the gradual upgrade approach for our test system will work as well in this scenario. I'll still have to adjust the dbid files and bring over the repository but other than that I think we are good to go. I'll admit that some of the information I was going throught (the stuff provided by HP) was lacking in some areas, mostly the database side of things which really left me confused.

0 Likes
Absent Member.. Trudy Claspill Absent Member..
Absent Member..

Re: Gradual Upgrade process for ALM

It needs to be pointed out also that one of the early replies in this thread said to "update the existing site admin schema".  In fact, I believe you need to instead update a copy of the schema.

 

If I understand this correctly, you have (at least one) app server running QC v10, and a separate database server.  You want to install a new app server with v11, but keep the original DB server.  You want to "gradually" upgrade your projects from v10 to v11 in this environment in such a way that projects not yet upgraded are still usable through the original app server with QC v10, and projects that have been upgraded are accessible only through the app server with QC v11.  If I have misunderstood, ignore the rest of this post. And setting up a replicated test environment is a whole different process. Otherwise, in order for that to work I believe you need to do the following.

 

When you install v11 on the new server and point it to the original DB server, tell it to upgrade a copy of the site admin schema.  If you do that, your QC v11 app server will point at the upgraded copy, and your original QC v10 server will continue to reference the original v10 site admin schema.  If you instead "upgrade existing", then your QC v10 server will no longer be able to reference the site admin schema because it will have been updated to be compatible with v11.

 

For each project that you want to upgrade, first Remove it from your v10 application to make it inaccessible to the v10 users.  And, by Remove I mean log into the v10 Site Admin module and select the Remove Project option (NOT Delete project).  Removing the project will make it inaccessible to the v10 system but leave all the data in place on both the DB server and the file repository in the v10 system.

 

Next, copy the repository directory from the v10 app server to the appropriate location named in the v11 app server as the repository location.

 

Within the new repository directory modify the dbid.xml file for the project to update the <PHYSICAL_DIRECTORY> tag to point to the new repository location.

 

Note also that the repository location for each project is ALSO stored in the site admin schema database.  You will need to directly edit this information in the v11 site admin schema database in the PROJECTS table for each project as it is upgraded, too, like you are doing for the dbid.xml files.

 

If you are following this procedure, then when you installed v11 you made a copy of the site admin schema.  As far as v11 is concerned, the project has existed all along and only needs to be verified, repaired, and upgraded.  Now that you have the project's repository in the new location and have updated that location info in the dbid.xml file and in the v11 site admin schema, you can proceed on the v11 Site Admin module with the verify, repair, and upgrade steps.

 

Note, thought, that any changes made at the Site Admin level on the v10 system since the v11 system was installed won't be relfected in the v11 system, because it is using a copy of the site admin schema.  That means any users added or removed, projects added or removed, domains added or removed, and configuration settings changed will have to be repeated in the v11 environment.

 

Let me put in this caveat.  I have set up replicated test environments where I had a whole new app server and new db server.  I have also done multiple upgrades in situ (5 versions in test and production environments) for QC.  I have not, however, tried to set up a new app server running a newer version of QC accessing an existing QC DB server currently in use with an older version of QC.  Nor have I used Oracle.  So, the above procedure is based on my related (but not identical) experience and interpretation of what I think you are trying to accomplish.  It hould not be assumed to be a specifically proven procedure. 

 

I hope this is helpful.

[If this post solves or helps solve your issue, mark the thread as solved and give KUDOS to the author for their assistance.]

(Opinions expressed in my postings are mine alone, and do not reflect the opinions of my employer.No warranties express or implied for any solution/suggestion posted.)
Absent Member.. Deb_1 Absent Member..
Absent Member..

Re: Gradual Upgrade process for ALM

Thanks guys for such a detailed information for upgrading the QC. We are currently assessing different option of updating QC 10 to 11 in our organization and these information really helps. My kudos to all

 

I have a question that linked to this thread I assume. 

 

Currently our QC 10 app server sits on 2003 server and repository on the same box (alias D drive), and DB server on Oracle. As part of the upgrade we are not going to touch DB as that server is part of the DB server farm and we won't change it. 

 

Now regarding app server, I am planning to upgrade it to new 2008 server (HP recommendation) i.e. Install QC 11 on a new server rather than using the existing one. But what I want is not to take repository to the new server, rather would like to keep on the existing D drive on 2003 server. Basically I want to split the app server from repository server. This is because we have huge amount of files on the repository and everyday we run  a back up process (TTS) to take back up files. In doing so, someday this process take all CPU (this is another issue and not relevant here) and making QC access unavailable to the users/testers . So if I will spin off the app server to a new box and leave repository on old machine, at least I have the app server always up and running and user can access it (may not attachments if repository box is down) 

 

So my query is anything wrong with this approach? 

Also if my app server is on Windows 2008 and repository path on 2003, will this create any problem? Both these boxes will be on same LAN and farm, so connection or networking won't be a problem. 

 

Please suggest

Thanks
Deb
0 Likes
Established Member.. William Schmitt
Established Member..

Re: Gradual Upgrade process for ALM

Deb,

 

Your approach is sound.  In fact, it is recommended to have your repository on a different server.  And it shouldn't matter that it is a 2003 server.  You just need to make sure that the ALM app id has read/write permissions to the repository share.  During the install, you enter the existing repository path.  Also, you must disable UAC on the 2008 server to install the ALM platform software.

 

Good luck,

William

0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Deb,

 

I'm re-doing our archetecture in a similar manner. We too are currently on Windows Server 2003 with our Oracle DB on a seperate server. I'll be doing a cluster setup on two new Windows Server 2008 VM instances and moving the repository to a Win2008 VM instance as well but leaving the DB as is.

 

I have good feelings this will go very well as opposed to my current project of setting up a testing/training environment where I'm cloning our Oracle database to a test system to test the upgrade. That has been a real headache.

 

Since our environments are very similar, if you would like to communicate more directly just send me a PM. I would be happy to share and discuss my trials and tribulations with you.

0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Trudy, as always you offer amazing info, thank you!

You were dead on so no missunderstanding there! My question is pertaining to my test/training environment. Production will be a little different as mentioned in my post to Deb below.
0 Likes
Steven Hulse Absent Member.
Absent Member.

Re: Gradual Upgrade process for ALM

Here is an update on my little adventure.

 

My test VM box is up and running, I have my production Oracle database cloned to our test environment, I've been able to install and connect ALM to the test database and run an upgrade of a copy of the existing schema. (I was having issues earlier getting it to see the DB.)

 

My current roadblock is removing all references to the production database. I'm currently working on updating the dbid files but there is still a reference in the database itself to the old production database. I have a call set up this afternoon with support to address this.

 

Once I get the references to the production database cleared up I'll begin the process to upgrade the projects. I'll keep you informed on my progress.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.