https://<server-host>:<jazz-port>/jazz/admin?internal#action=com.ibm.team.repository.admin.serverReset
これで、IBM Installation Manager で「変更」を選択して言語を追加または削除することができます。
| Rational Team Concert Client のバージョン | 互換性のある Jazz Team Server のバージョン |
|---|---|
| 1.0.x for Eclipse | 0.6.x |
| 2.0.x for Eclipse | 1.0.x |
| 2.0.0.0 for Microsoft® Visual Studio | 1.0.0.0 |
| 2.0.x for Microsoft Visual Studio | 1.0.x |
Client for Eclipse IDE のバージョン 1.0、1.0.1、または 1.0.1.1 を使用している場合は、2.0.x のクライアントを入手して、新しいバージョン 2.0.x のサーバーに接続する必要があります。 zip ファイルを使用してこれをインストールすることも、IBM Installation Manager による以前のインストール済み環境を更新することもできます。
Rational Team Concert のアーリー・アクセス版を実行している場合は、まず、2.0.0.2 のトライアル版にアップグレードします。
サーバーを 2.0.0.2 のトライアル版から永続版にするには、ご使用のエディション用のサーバー・アクティベーション・キットを購入してインストールします (http://www.ibm.com/software/awdtools/rtc/ で入手可能)。 アクティベーション・キットは、永続サーバー・キーを含む JAR ファイルで構成されています。 インストールは、サーバーの管理 Web インターフェースの「ライセンス・キーの管理」ページを使用して行います。
Rational Team Concert の以前のリリースから 2.0.0.2 リリースに直接アップグレードできます。 1.x から 2.x への更新では、データベースのマイグレーションが必要です。データベースのマイグレーションの実行については、Jazz Team Server アップグレード後の Jazz リポジトリーのマイグレーションを参照してください。
以前のリリースを zip ファイルからインストールした場合は、以前のインストールとの共通部分はありません。 zip から新規ロケーションに 2.0.0.2 リリースをインストールすることも、IBM Installation Manager を使用して 2.0.0.2 のインスタンスをインストールすることもできます。
IBM Installation Manager を使用して以前のリリースをインストールした場合は、2.0.0.2 を別のインスタンスとしてインストールするか、以前のインスタンスを 2.0.0.2 に更新することができます。 2.0.0.2 リリースを別のサーバー・インスタンスとしてインストールする場合は、インストール・ウィザードの「パッケージのインストール」ページで「新規パッケージ・グループの作成」を選択します。
アップグレードを完了するには、『以前のサーバーのインストール済み環境から必要な構成ファイルをコピーする』および『2.0.0.2 のアクティベーション・キーのインストール』を参照してください。
Rational Team Concert のエディション間でアップグレードができます。 代表的なアップグレードには、Express-C から Express® への移行や、Express から Standard への移行などがあります。同じプロセスに従って、逆方向にダウングレードすることもできます。
Rational Team Concert 2.0.0.2 では、すべてのエディションで Derby データベースがサポートされているため、Express-C から Express または Standard に移行する場合には、Derby から DB2® または Oracle にマイグレーションする必要はありません。 まずサーバーのエディションをマイグレーションして、既存のデータベースの処理に問題がないかどうかを確認し、必要に応じてデータベースのマイグレーションを実行することをお勧めします。 Derby データベースでは、10 ユーザーまでしかサポートされないことに注意してください。 データベース・マイグレーションの実行については、Jazz Team Server アップグレード後の Jazz リポジトリーのマイグレーションを参照してください。
Rational Team Concert 2.0.0.2 のエディションが既にインストールされていて、それを別のエディションにアップグレードする場合は、新規エディションをダウンロードして既存のエディションと並行する形でインストールし、新規エディションの実行に必要な構成ファイルをコピーします。 以下のセクションで、必要な構成ファイルについて説明します。
以前のエディションを zip ファイルからインストールした場合は、以前のインストールとの共通部分はありません。 zip から新規ロケーションに新規のエディションをインストールすることも、IBM Installation Manager を使用して新規のエディションをインストールすることもできます。 実動サーバーについては、今後の更新を適用できるようにするために、IBM Installation Manager を使用することをお勧めします。
以前のサーバー・インストールを IBM Installation Manager を使用して実行していて、新規エディションのインストールにも IBM Installation Manager を使用する場合は、Installation Manager での新規インストール時に、以前のエディションをオーバーレイしないでください。 インストール・ウィザードの「パッケージのインストール」ページで「新規パッケージ・グループの作成」を選択します。
こうすると、新規エディションが別のロケーションにインストールされ、新規のパッケージ・グループ名を使用してプログラムのショートカットが作成されます。
Installation failed.
Error during "install" phase:
Failed to extract zip standard 1.0.1.I20081018-1820. File
D:¥JazzTeamServer¥server¥license-update-site¥site.xml already exists.
これが発生しても、致命的なエラーではありません。インストールを再開して、新規パッケージ・グループを正しく作成できます。
file:///<JazzInstallDir>/server/conf
以下のファイルをソース・サーバーからターゲット・サーバーにコピーします。 まず、アップグレードするサーバーのインストール済み環境にあるオリジナル・ファイルの名前を変更して、バックアップを作成します。IBM Installation Manager を使用して、1.0、1.0.1、1.0.1.1、または 2.0 から 2.0.0.2 に更新した場合は、1.0.x または 2.0 の構成ファイルを含むバックアップ・ディレクトリーが、backup-config-timestamp などの名前で、インストール・ロケーションのサーバー・サブディレクトリーに作成されています。
Standard Edition または Enterprise Edition にアップグレードする場合、Developer Client Activation Kit for Express を購入済みであれば、Developer Client Activation Kit for Standard Edition または Enterprise Edition を購入してインストールしてください。そうすれば、それぞれのクライアント・ライセンスを使用できます。 開発者ライセンスの割り当ては引き続き有効ですが、正しいアクティベーション・キットがインストールされるまで、開発者ライセンスは非アクティブ化されます。
2.0.0.2 リリースでは、2.0.0.2 のアクティベーション・キーを使用します。 サーバーを 1.0.x.x から 2.0.x にアップグレードすると、アップグレード後にトライアル・ライセンスに戻ってしまいます。そのため、IBM Rational® License Key Center から 2.0 または 2.0.0.2 のアクティベーション・キーを入手する必要があります。
IBM Rational License Key Center について詳しくは、IBM Rational ライセンスのサポート・サイトおよび関連する jazz.net Tech Tip を参照してください。
各キットに対する適用可能なキーの名前を以下に示します。
Rational Team Concert 1.x では、プロジェクトは複数の予定表 (以前の名前は「開発ライン」) を持つことができ、これらの予定表はすべて同等と見なされていました。
Rational Team Concert 2.0 では、プロジェクトは引き続き複数の予定表を持つことができますが、「プロジェクト予定表」のマークを付けることができるのは、そのうちの 1 つだけです。 データベースを 2.0 にマイグレーションすると、プロジェクトの 1 次予定表がわからないため、プロジェクトにプロジェクト予定表が設定されていない状態になります。 2.0 へのアップグレード後には、プロジェクトを手動で更新して、プロジェクト予定表を設定できます。
データウェアハウスのソース管理 (SCM) スナップショットでは、ストリームに関するデータ (ストリームのサイズに関する情報、および変更セットやファイル/フォルダーの変更のような、ストリーム内のアクティビティーに関する情報など) が収集されます。 バージョン 1.0 では、このスナップショットにより、すべてのストリームに関する情報が自動的に収集されました。 この操作は負荷がかかる可能性があるため、バージョン 2.0 では、SCM スナップショットに構成可能性のオプションが追加され、データを収集するストリームをユーザーが決められるようになりました。 この変更による直接の影響は、これを構成しない限りデータは収集されないということです。
以降のすべてのスナップショットで、選択したストリームのデータが収集されます。
これらは注意していないと非常に重大な問題になる場合があります。レポートによって収集されるデータが誤っている可能性があるためです。 BIRT 2.3.2 Report Designer で最初にレポートを編集する際には、必ず各データ・セットおよび各レポート・パラメーターを確認することをお勧めします。 これらの問題は、BIRT 2.3.2 のツールで作成した新規レポートでは発生しません。
上記の変更は、Rational Team Concert 2.0 で提供されている、すぐに使用可能なすべてのレポートに対して行われます。ユーザー側のアクションは必要ありません。 ただし、すぐに使用可能なレポートを使用してプロジェクト・エリアに手動でレポート・テンプレートを作成したが、適切な ID (用途に一致するもの) を指定していない場合は、レポート・テンプレートをマイグレーションしてもリフレッシュされません。 つまり、内容が古くなり、機能しなくなります。 その場合は、すぐに使用可能な .rptdesign ファイルのうちの適切なものを使用して、影響を受けるテンプレートに新規の内容をアップロードしてください。
Rational Team Concert 2.0 では、データウェアハウスのワークアイテム表にいくつかのスキーマ変更が行われました。 その結果、1.0 から 2.0 にマイグレーションする際に、インポーターがウェアハウス内のワークアイテム・データを無視します。 そのため、2.0 のサーバーを初めて始動する際に、ワークアイテム・レポートが正常に機能しない可能性があります。 回避策は、最初のワークアイテム・スナップショットが実行されるのを待つか、サーバーの始動後に手動でこれを実行するかのいずれかです。 ワークアイテム・スナップショットは、マイグレーション後の最初の実行時に、データウェアハウス内のすべてのヒストリカル・ワークアイテム情報を再構成します。 これは、マイグレーション後の最初のスナップショットの実行には、平均的な夜間の実行よりもはるかに長い時間がかかる場合が多いことをも意味します。
ダイアログが表示され、使用可能ではあるが、まだプロジェクト・エリアにデプロイされていないレポート・テンプレートをディスカバーすることができます。 ここで選択したレポート・テンプレート (複数可) が作成されます。 作成後は、選択可能なメニュー・アクションを使用して、それらのテンプレートから新規レポートを作成できます。
ワークアイテム・タイプ、属性、ワークフロー、役割、およびイベント・ハンドラーに対して行った変更は、1.x から 2.0 にアップグレードする際に保存されます。 定義済みプロセス・テンプレート (スクラムなど) をカスタマイズした場合は、その定義済みテンプレートを (「プロセス・テンプレート」ビューで) 再デプロイすると、カスタマイズした内容が上書きされることに注意してください。 定義済みのテンプレートを再デプロイする必要がある場合は、カスタマイズした定義済みテンプレートの名前および ID を最初に変更しておくと、上書きされません。