Evolving your topology

Introduction

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.

How do I separate a Jazz Team Server from an application?

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 version of the JTS must always be at the same version as your highest application. For example, if you have RTC 4.0.1; RQM 4.0.1; and RRC 4.0.2, your JTS must be at least version 4.0.2.

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.

• Stop the current Tomcat server for your apps and JTS (assume just Rational Team Concert)
• Install JTS with a new Tomcat instance into a new install directory
• Copy across the JTS tomcat applications the configuration details from old server to the new copy the teamserver*.properties for /jts and /admin
• Copy the user authentication files across:
  • If you use LDAP, then copy the following tomcat/conf files:
  • JazzTeamServer\server\tomcat\conf\server.xml
  • JazzTeamServer\server\tomcat\webapps\jts\WEB-INF\web.xml
  • JazzTeamServer\server\tomcat\webapps\admin\WEB-INF\web.xml
  • If you are using the Tomcat users registry, then copy the JazzTeamServer\server\tomcat\conf\tomcat-users.xml file instead
• Copy indices install_dir/server/conf/jts/indices to the new tomcat install, if not it has to be created again on the new server with repotool-jts
• Configure the new tomcat to use other ports than the first one. Make sure the new JTS Tomcat server listens on a different port number.
• Update the reverse proxy so that the JTS URL points to the new JTS Tomcat server
• Undeploy JTS from the original Tomcat server so that it will only run the RTC server
• Start the new JTS Tomcat server
• Start the old Tomcat server which now serves only the RTC application (and the other application servers).
• Test that everything is working correctly, specially links from jts to ccm and back from ccm to jts
• Stop both tomcat servers, make backup so that it can be reverted to this two server configuration at any time.

You will have to make sure that you either get / create a personal certificate from/on the new JTS server or get one from a Certificate Authority (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, any relocated application will also need a certificate regenerated.

For more information on configuring certificates and reverse proxy, please refer to the specific section within this wiki that is dedicated to this.

How do I undeploy an application or Jazz Team Server using IBM Installation Manager?

How do I manually disable and undeploy an application below describes how you can achieve this manually if you did not use Installation Manager to install your Jazz solution.

If you used IBM Installation Manager, then you can follow the steps here to modify your installation to remove an application, or the Jazz Team Server itself.

• Start Installation Manager
• Select Uninstall
• Select the Jazz Team Server box next to the instance that you wish to uninstall.
  • Also select Trial keys for Collaborative Lifecycle Management Products, although you will be reminded/prompted if you forget this step.
• Press the Next > button
• Confirm that the Backup Location corresponds to the location where your Jazz installation resides, if you have multiple instances of Jazz installed.
• In the Uninstall Packages page, ensure all of the above selections are confirmed and then press the Uninstall > button

How do I manually disable and undeploy an application?

This answer is taken from the forum and applies to Tomcat.

• First unregister the applications from JTS
  • Access https://server:port/jts/admin#action=com.ibm.team.repository.admin.registeredApplications
  • Delete the applications that you wish to disable
• Move the application's files
  • Stop the server
  • Move the relevant files and folders out of the webapps directory based on the specific application you wish to disable \server\tomcat\webapps
  • The applications' files and folders are listed below in the table:

    Application	Files	Folders
    RM Application	rm.war, converter.war	rm and converter
    QM Application	qm.war	qm
    CCM Application	ccm.war	ccm

• If the related xml files exist under \server\tomcat\conf\Catalina\localhost, remove them. For example, delete converter.xml, rm.xml for RM application
• Clear out the work directories under \server\tomcat\work
• Re-start the Server

Related topics: Recommended CLM deployment topology, Recommended SSE deployment topology, Server Rename, Reverse Proxy

External links:

• IBM

Additional contributors: TWikiUser, TWikiUser