Staging a test environment for the upgrade process

There are ways to set up a test environment to avoid issues with absolute URL links between Jazz™ Team Server and Jazz-based applications.

The Jazz Team Server and Jazz-based 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.

This also creates special requirements for testing 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. Therefore, you must ensure that there is isolation between the test environment and the actual production repositories.

The ideal setting for a staged environment is a completely isolated subnet with no visibility to the real production server. Where this is not practical, some simpler techniques can be used 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 the each application and Jazz Team Server.

Option 1: Test everything from within one machine

You can test from within one machine only if you are testing the upgrade of a single application, for example, Rational Team Concert™.

Option 2: Test with multiple servers

You can use this option if you have multiple applications on different servers.

Option 3: Test with remote clients

You must use a dedicated client workstation for testing that is not used in any production environment.

Option 4: Separate subnet

This option provides the greatest isolation, but is the most complex.