Staging a test environment for the upgrade process
You can set up a test environment to verify your upgrade process with real data before upgrading your production server.
The Rational solution for CLM applications are uniquely identified within a network by their public URL, also known as front side URL or public URI root. The server and applications generate absolute URIs to resources that are used in stored artifacts, mail notifications, feeds, web access, and for stable resource identification across all applications. This ensures uniform access to all resources stored in various repositories, and consistent query results based on artifact URLs. Special consideration has to be taken to maintain the Public URI in the test environment and to avoid issues with absolute URL links between the testing environment and Jazz® Team Server and other applications in production.
This also creates special requirements for testing an upgrade using a replica of production data in a staged environment. The persisted URLs in the repositories still refer to artifacts by their production public URL. This is true especially for cross-application links like a test artifact to a work item link, but can also be true for artifacts stored in a single application repository with self-referencing URLs. Ensure that the repositories for the test environment and the actual production are isolated from each other.
The ideal setting for a staged environment is a completely isolated subnet with no visibility to the real production server. Where such a setup is not possible, you can use simpler techniques with caution.
Consider the following techniques to provide isolation and allow meaningful testing. The techniques are listed in order of complexity. In each of these cases, the prerequisite step is to restore a copy of the production database to a test database server. Maintain the same configured public URL for each application and the Jazz Team Server.
Option 1: Test all server applications from within one machine
You can test everything from within one machine if the applications to be tested are hosted in production on the same machine and if the test server has enough resources.
- Edit the hosts file on the test server machine. You can configure
an alias for your server by adding the following entry to your system
hosts file: 127.0.0.1 qualified.hostname. Substitute qualified.hostname with
the fully qualified host name used in your production public URL.
The hosts file is in the following locations:
- Linux®: /etc/hosts
- Mac: /etc/hosts
- Windows: C:\windows\system32\drivers\etc\hosts
- IBM i: Run the command CFGTCP and then enter option 10.
Option 2: Test with multiple servers
You can use this option if you have multiple applications on different servers.
- Collect a mapping of the public URLs for each server to the IP addresses of the test server machines that are used.
- Edit the hosts file on each test machine with mappings for all of the test machines acting as staging servers.
Option 3: Separate subnet
This option provides the greatest isolation, but is the most complex.
- Place the test servers and test clients behind a router with no access to the production network.
- Configure a DNS server within this subnet and map the public URL host names to the IP addresses of the test server machines that are used.
To validate your staging environment, you will need to connect clients to the staged server, for example, a web browser or the RTC rich client. The connections will have to resolve to the hosts in the staging environment and not production. You should either run these clients on one of the server machines in the staging environment, or use a dedicated client workstation, that also includes all of the host mappings, and is not used in any production environment.