First Look at Migrating Jazz-based Products to 3.0.1

I haven’t posted in weeks because we’ve been locked in a room testing the migration of Jazz-based products to version 3.0.1, otherwise known as Collaborative Lifecycle Management (CLM). It’s time to come up for some air and give you a glimpse of what to expect when it comes time to migrate your products to the new version.

Since this is my first post on upgrading, I’m going to skip a lot of detail (and there is a LOT of detail). Instead I’ll provide a high-level view of what upgrading means, and dive down into details in future posts.

This article applies to the CLM products and server:

  • Rational Team Concert (RTC)
  • Rational Quality Manager (RQM)
  • Rational Requirements Composer (RRC)
  • Jazz Team Server (JTS)

First, there ain’t no such thing as an upgrade to 3.0.1 from 2.x for RTC, RRC, or RQM. Or from the Jazz Team Server (JTS) for that matter. What’s called “upgrading to 3.0.1” is really a migration. There have been fundamental architectural changes in JTS and by extension the three CLM applications. There’s no way to just push a button and have your current installation get upgraded in-place. Instead you install the latest version of the software in a new location on your existing machine, and migrate your data and configuration information to the new installation. This includes application data, server data, the data warehouse, and a host of configuration files.

Did I mention that the upgrade (or migration) can be complex? You probably know that a single application like RTC can run on 4 different databases, 2 different web servers, and few different operating systems (including flavors on Linux and x32/x64 platforms). Now multiply that by 3 applications, a new shared Jazz Team Server, dependencies between applications that link to each other’s data (the building blocks of CLM), upgrade constraints, server and naming constraints that affects future expansion, a new licensing model, etc, etc. There are more permutations of Jazz-based system than can be specifically enumerated, though there is a set of common upgrade scenarios that cover most organizations.

You buy a lot by doing the upgrade and/or migrating to CLM, but don’t approach the upgrade like it’s going to be a breezy afternoon. Plan on upgrading one application at a time. Verify and stage the migration to achieve confidence and stability before upgrading the next application.

Fortunately, CLM applications are compatible when working with newer versions of JTS and other CLM applications. So you for instance can upgrade your RRC application and server to RRC 3.0.1 and JTS 3.0.1, while RTC and RQM stay on 2.x until you’re satisfied with the migration.

One of the main considerations when upgrading is what your new CLM architecture will look like. Up to now, each application has had its own Jazz server. In 3.0.1, the applications can share a server. This means you can:

  • Perform Lifecycle Project Administration (LPA), managing users and projects across applications instead of trying to keep the same users in sync on different applications.
  • Manage the load better for your enterprise
  • Take advantage of more powerful CLM associations.

The tradeoff is that you now need to consider what your Jazz-based architecture is going to look like: A single JTS? One JTS for each application? A JTS for each department in your organization? It’s not possible at this time to change the URL for a JTS, or move an application to a different JTS once it’s been registered with a JTS. So careful planning beforehand is critical.

For example you’ll want as few JTSs as possible. This will simplify administration and make licensing easier and more efficient. LPA and common reporting, for instance, can only be performed on projects within a single JTS, not across JTSs. But if different departments want to run their own project configurations and servers, or if you need to spread the load out among multiple JTSs, you’ll need to make important decision about your server architecture.

I’m developing a set of rules for installation/migration to CLM 3.0.1. Read the rules before you design your installation so you can understand your constraints and plan accordingly.

More to come…


Advertisements
This entry was posted in Uncategorized and tagged , , , , , , , , . Bookmark the permalink.

One Response to First Look at Migrating Jazz-based Products to 3.0.1

  1. SpicyNeuron says:

    Very true. Always practice on a cloned PROD environment. In other words: Perfect Planning Prevents Poor Performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s