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 バージョン |
|---|---|
| Eclipse 用の 1.0.x | 0.6.x |
| Eclipse 用の 2.0.x | 1.0.x |
| Microsoft Visual Studio 用の 2.0.0.0 | 1.0.0.0 |
| Microsoft Visual Studio 用の 2.0.x | 1.0.x |
バージョン 1.0、1.0.1、または 1.0.1.1 の Client for Eclipse IDE を使用している場合は、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 での新規インストール時に、以前のエディションをオーバーレイしないでください。 インストール・ウィザードの「パッケージのインストール (Install Packages)」ページで「新規のパッケージ・グループの作成 (Create a new package group)」を選択します。
これによって新規のエディションが別のロケーションにインストールされ、新規のパッケージ・グループ名を使用して、プログラム・ショートカットが作成されます。
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 技術ヒント を参照してください。
各キットに適用可能なキーの名前を以下に示します。
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 つ以上選択すると、それらが作成されます。 作成後は、選択可能なメニュー・アクションを使用して、それらのテンプレートから新規レポートを作成できます。
ワークアイテム・タイプ、属性、ワークフロー、役割、およびイベント・ハンドラーに対して行った変更は、1.x から 2.0 にアップグレードする際に保存されます。 定義済みプロセス・テンプレート (スクラムなど) をカスタマイズした場合は、その定義済みテンプレートを (「プロセス・テンプレート」ビューで) 再デプロイするとカスタマイズ内容が上書きされることに注意してください。 定義済みのテンプレートを再デプロイする必要がある場合は、カスタマイズした定義済みテンプレートの名前および ID を最初に変更しておくと、上書きされなくなります。
この情報は参考になりましたか。Jazz.net でフィードバックをお送り頂けます (登録が必要です): フォーラムにコメントを記入したり、バグを送信したりすることができます。