プロジェクトの移行を準備する
これらの手順は Jira Server と Data Center の異なるインスタンス間で移行する際のものです。また、サード パーティ アプリである Project Configurator for Jira が必要です。Server から Cloud に移行する場合は、「Jira Server から Cloud への移行リソース」をご参照ください。
バージョン
ソースとターゲット インスタンスの Jira バージョンを同じにすることをおすすめします。そうでない場合、インスタンスのいずれかをアップグレードすることをおすすめします。
ただし、場合によっては、これらの制限を回避できます。
異なる Jira バージョン間の移行
- ターゲット インスタンスの Jira バージョンがソース インスタンスよりも古い場合、ターゲット インスタンスをアップグレードする必要があります。
- ソース インスタンスの Jira バージョンがターゲット インスタンスより古い場合、2 つの方法を利用できます。
- ソース インスタンスをアップグレードします。
- ステージング サーバーを使用した移行。次の手順に従います。
- ターゲット インスタンスをステージング サーバーに複製します。
- ソース インスタンスの XML バックアップを作成します。
- ステージング サーバーでバックアップを復元します。これにより、ステージング サーバーのすべてのコンテンツが削除され、移行されたデータが最新バージョンに更新されます。
- Project Configurator for Jira を使用し、このガイドで説明した手順で、ステージング サーバーからターゲット インスタンスにプロジェクトを移行します。
ディスク容量の要件
移行の際には、次の情報を含む ZIP アーカイブにプロジェクトをエクスポートします。
- エクスポートしたプロジェクトの設定
- これらのプロジェクトの課題 (添付ファイル、コメント、作業ログ、履歴など)
ZIP アーカイブを作成する前に、コンポーネントは一時ディレクトリに集められ、最終的な ZIP アーカイブよりもより多くのスペースが必要となります。一時ディレクトリは、最終 ZIP アーカイブの約 4 倍のサイズにすることをお勧めします。
計算式を使用して、ZIP アーカイブのおよそのサイズを計算できます。これを行うには、次の情報が必要です。
- データベースの XML バックアップのサイズ。
- インスタンスのプロジェクトの合計数、および移行したいプロジェクトの数。
- 移行されたプロジェクトの添付ファイルのサイズ。各プロジェクトの添付ファイルは、<Jira-home-directory>/data/attachments 内の個別のディレクトリに保存され、各ディレクトリにはプロジェクトの最初のキーにちなんだ名前が付けられます。このパスは既定ディレクトリです。これは Jira の
> [システム] > [添付ファイル] で確認できます。
- 次の式を使用します:
データベースのサイズ * 移行したプロジェクト/すべてのプロジェクト * 1.2
例えば、データベースのサイズが 500 MB で、20 プロジェクトのうち 5 つを移行したい場合:
500 MB * 5/20 * 1.20 = 150 MB - 次に、移行したプロジェクトの添付ファイル サイズを確認し、別の式を使用します。
添付ファイルのサイズ / 4
例えば、添付ファイルのサイズが 300 MB の場合:
300 MB / 4 = 75 MB
上記の例を使用すると、ZIP アーカイブの最終的なサイズは 225 MB となります。一時ディレクトリのディスク容量は、ZIP アーカイブのサイズの 4 倍にする必要があるため、約 1 GBとなります。ZIP アーカイブは Jira へのインポートする前にターゲット インスタンスで展開されるため、ソース インスタンスとターゲット インスタンスの両方に同じディスク容量が必要です。
ライセンス
ターゲット インスタンスのユーザーに十分なライセンスがあることを確認します。そうでない場合、移行後に追加するか、いくつかのユーザーを非アクティブ化する必要があります。詳細については、「ユーザーの作成、編集、削除」を参照してください。
ユーザー管理
移行中のユーザー管理はと固有の環境によって異なりますが、次の規則を考慮する必要があります。
- ユーザーはユーザー名 (Jira の ユーザー名 フィールド) によって、ソース インスタンスからターゲット インスタンスにマッピングされます。1 人の人物が両方のインスタンスに異なる名前を持つ場合、それらを統一する必要があります。
- いずれかのユーザーを変更するか、
- ユーザーが、両方のユーザー名で一部の属性が同じ LDAP を使用して外部ディレクトリで管理されている場合、「username」として動作するよう設定できます。
- 外部ディレクトリで管理されているユーザーは、次の方法で移行できます。
- 外部ディレクトリに特定のツール (例: LDAP インスタンス全体でユーザーを複製する)。この場合、プロジェクトに移行する前にユーザーを移行する必要があります。これらはプロジェクトの設定の一部 (例: 権限) で参照される可能性があります。
- Project Configurator for Jira。詳細と制約については、「一部のオブジェクト タイプに特有の情報」を参照してください。
- 両方の組み合わせ。
これらの考慮事項はグループ管理にも適用されまｍす。
両方のインスタンスのプロパティを一致させる
両方のインスタンスで次のプロパティが同じであることを確認します。
- タイムゾーン
- ロケール (特に数字や日付を文字列に書式設定する方法を定義するルール)
- テキスト フィールドの最大サイズ (ターゲット インスタンスのサイズは、ソース インスタンスのサイズより大きくすることができます)
テキスト フィールドのサイズ上限設定の詳細は、こちらをクリックしてください。
設定オブジェクトの名前
移行プロセスは、両インスタンスにある同じ名前の設定プロジェクトを、同じものとして処理します。ほとんどはこれで問題ありませんが、同じ名前の 2 つのプロジェクトが全く異なる場合もあります。ソースは、実装対象の、より新しい設定を表しているとみなされるため、ソースの設定によってターゲットの設定が上書きされます。一部の項目が失われるのを防ぐため、以下を実行します。
- 両方のインスタンスで、グローバルに利用可能な設定オブジェクトの名前を確認します。
- 一致がある場合、これらの名前が実際に同じオブジェクトを表しているかどうかを確認します。
- 間違ったデータに上書きされるのを防ぐため、必要に応じて、いずれかのインスタンスでオブジェクトの名前を変更します。
Project Configurator は、この課題に役立ついくつかの機能を提供します。
- インポートの競合検出 - ソース インスタンスからのオブジェクトにマッピングされる、ターゲット インスタンス内のすべての設定オブジェクトのサマリー レポートを生成します。また、このレポートには、重複オブジェクトがターゲット インスタンスのどこで使用されているかも表示されます。
- 「使用中」レポート - 設定オブジェクトがどこで使用されているかを示します。これらのオブジェクトの名前を変更、またはオブジェクトを変更/削除する必要がある場合に便利です。
カスタム フィールド タイプを定義するプラグイン
ソース インスタンスのカスタム フィールド タイプを定義するプラグインは、同じバージョンがターゲット インスタンスにインストールされている必要があります。
ワークフロー拡張機能を定義するプラグイン (条件、バリデーター、事後操作)
ソース インスタンスのワークフロー拡張子を定義するプラグインは、同じまたはより新しいバージョンがターゲット インスタンスにインストールされている必要があります。
- ソース インスタンスからのワークフローは、ターゲット インスタンスへ移行されます。必要なプラグインがない場合、ワークフローは作動しない可能性があります。
- プラグインをインストールしていない場合、対応するワークフローの「トランジションの作成」操作が、ターゲット インスタンスへインポートされる各課題に対して実行されるため、インポートが失敗する可能性があります。
アジャイルボードの移行
アジャイル ボードの移行はサポートされていますが、Jira 6 を使用している場合、Jira Agile 6.7.7 以降であることを確認してください。それより古いバージョンでは、ボードを移行できません。
スプリントとランキング データの移行
スプリントとランキング データの移行は、Jira Software でのみサポートされます。Jira Agile のデータは無視されます。
言語とロケール
ソース インスタンスとターゲット インスタンスは、同じ言語とロケールでインストールされている必要があります。Jira Software は言語設定に応じて異なる名前でフィールドを作成します。これは、インスタンスのいずれかが英語 (US) を使用し、もう 1 つが英語 (UK) を使用している場合でも発生します (例: 「Epic Color」と「Epic Colour」)。詳細は、この課題を参照してください。
重複した古いランク フィールド
場合によっては、Jira Software をアップグレードすることで、Rank タイプのフィールド、"Rank" (廃止済み) が作成されます。移行するプロジェクトがこれらのフィールドを使用する場合、移行中にエラーが発生する場合があります。これらのカスタム フィールドは通常ロックされているため、Jira Software が作成または設定する必要があります (Project Configurator はこれをターゲット インスタンスに作成しません)。結果として、ソース インスタンスとターゲット インスタンス内のプロジェクトが別のフィールド セットを使用していることになるため、移行が失敗します。
これらの課題を避けるには、次の手順を実行します。
- ソースとターゲットの両方に Jira Software がインストールされていることを確認します。
- ソース インスタンスに重複したランク フィールドや古いランク フィールドがある場合、それらのフィールドおよび関連するランク値を削除します。詳細は、JIRA KB 記事と JSW-13098 を参照してください。