It's all about the answers!

Ask a question

Best NEW information on redeploying an old installation

Cliff Sadler (42110) | asked Mar 15, 3:11 p.m.

 10 years later, and we've all learned a lot about deploying CLM and server resources.

I have an existing deployment, built on Jazz 2.0 Team Concert, 4.0 Quality Management, that has been upgraded, and cobbled together over the years.  The result is this:
one server with JTS, JAZZ (ccm), RM, and starts and stops of lqe, and data warehouse.  Now at 6.0.4 It's DB2 databases reside on the same server.
another server with JTS, qm. Now at 6.0.4  It's DB2 databases reside on the same server.
These two servers have different fully qualified domain names.
there are existing link relationships between qm data, and work items in ccm, and between requirements in rm, and  work items in ccm.
I'd like to "start over" as best we can.

I have consensus from the team that we can begin anew with the qm server, and unless we find a better way, will be hand jamming the test plans, cases, procedures, and steps back in manually.

We want to keep the Team Concert data, so that server name will have to remain the same.
I would like to move the rm server off of the ccm server and on to its own. If I can find a way to export the rm data and its links to ccm for reuse in the new server, that would be great (REQIF?).  It's only one module at this point (2000 artifacts), so again, may be easier to just get a record of who links to who, and then deal with that later manually.
Where it really starts getting fuzzy is about JTS.  Is is possible to stand up a JTS server on its own, add the users, and then friend up the existing ccm server and new qm server while shutting off the existing JTS on the ccm server?

Finally, I would move the DB2 databases for all applications to its own server, and I think I can just adjust the configuration to point to the new DB2 locations.

Accepted answer

permanent link
Davyd Norris (5055) | answered Mar 17, 6:11 p.m.
edited Mar 17, 6:16 p.m.
You don't have to go to the lengths you're talking about to get a decent installation set up from where you are right now. I would do this in a couple of stages:
 - set up DB2 on the new server, set up your DB2 database user etc., then move the existing databases over. Then simply point the current installation at the new location of the database. This can be done manually by editing the conf files, or just by rerunning the CLM setup and entering the new information.
 - work out which applications you want to run on what servers, and install appropriate apps of the latest CLM on your the new application servers. Just install, don't start them or anything yet. Don't even worry about names of servers yet.
 - install and set up a reverse proxy server. This server will provide a single URI for everyone to connect to, and then pass the calls to the appropriate back end server. Set up the proxy rules to pass the correct paths to the appropriate CLM app server. There are examples of how to do this in the jazz wiki, and this is the single most important step to having a scalable CLM system.
 - work out what URI you want to use for the whole CLM system, and set the proxy up to use this URI, with appropriate certificates etc.
 - work out which applications currently do not use this URI, and plan to perform a rename operation on those
 - now stop your existing servers, and copy your old installation(s) over to each of the new servers, putting the files into a separate temp directory
 - for each machine, starting with the JTS application server, perform a CLM upgrade or rename/upgrade operation. Use the old server file copy as the previous installation, and check the conf files after the upgrade to make sure that all the new locations are in the new app server file system. I like to set up the index caches in their own directories outside of the installation so that future upgrades are easier.

Note that once you have your proxy in place, it is possible to point it to the existing installation and do the rename on the existing system, however doing it on the new system means you have your old CLM to easily fall back to. Leave your old servers and the old DB2 server (including the backup files) intact until you have everything upgraded and tested out. If worse comes to worst, you can just drop the new servers and fire up the old ones again, and do over.Speaking of which, you can follow these steps and do a trial upgrade/rename using a completely different URI then blow everything away and do it for real once you feel confident.

There's no need to do any sort of export/import on anything - it will all still be there and linked up after the move.

**UPDATE**: the one other thing I would probably do (depending on how many users you have) is set up a separate LDAP server for the users, and point each of the applications to that central LDAP server. Make sure you use exactly the same uid for the users so that it will match up with the data that's currently in CLM. This will make user management across the multi server infrastructure much simpler.

You can do the LDAP and the DB2 changes as separate steps before or after the main move, however once again there's benefit in leaving your original install completely as-is so you can easily roll back if you need to.
Cliff Sadler selected this answer as the correct answer

Cliff Sadler commented Mar 18, 9:27 a.m.

Thank you for the insight.  I was thinking a similar path, but yours is cleaner, and allows a roll-back. 

Your answer

Register or to post your answer.