It is typical for a project to download the Jazz software from jazz.net and then install this in a proof of concept scenario, in order to demonstrate the applications to potential users/management/stakeholders. In some circumstances, those new projects using the proof of concept will start adding production data. You soon have a key system using completely under-powered hardware in an environment, which was never intended or planned, for production use.
The above pattern is just one scenario where you would want to move Collaborative Lifecycle Management (CLM) or Systems and Software Engineering (SSE) collocated applications to a new topology. It is also quite conceivable that you started off with just one project and are now on your way to many, many more! If you are, then you will need to evolve your topology.
The Deployment Planning and Design section of this wiki explains the different types of topology.
The base example that this article will use is the CLM V1 Evaluation single server topology and how to evolve from this.
An assumption of these evolutions is that in moving your applications and/or Jazz Team Server from one location to another, there was some planning performed when URIs were defined. It is most common that a reverse proxy was setup for this, but we have also seen Tomcat Virtual Hosting used instead. Ultimately, if you also need to change your URI, then you will need to be at least at version 4.x to take advantage of Server Rename.
Once you register an application with a JTS, it is not possible to change that association by re-registering with a new JTS. It is only possible to change the location of the Jazz Team Server.
The assumption here is that you will move the Jazz Team Server (JTS) from the incumbent server onto its own hardware/Virtual machine as you evolve from the CLM V1 Evaluation single server topology to a recommended CLM deployment topology or a recommended SSE deployment topology. These instructions also account for a reverse proxy.
Backup everything so that you are sure that you can restore your original deployment should anything untoward occur during this procedure.
They will have to make sure they either get / create a personal certificate from/on the new JTS server or get one from a CA and then import that certificate into the key that is referenced in the httpd.conf file. You will have to do this with your other applications servers too, if you move those. This is not just a step for the JTS.
To be completed
This answer is taken from the forum and applies to Tomcat.
Application | Files | Folders |
---|---|---|
RM Application | rm.war, converter.war | rm and converter |
QM Application | qm.war | qm |
CCM Application | ccm.war | ccm |
Status icon key: