Jira Cloud Migration Assistant での重複とエンティティの追跡

要約

Jira Cloud Migration Assistant は、エンティティのレコードを保存し、エンティティへの変更を追跡します。これによって次を防止できます。

• 元のサイトと移行先サイトの間で一致しないプロジェクトの構成 (ワークフロー、カスタム フィールド、スキームなど) の共有。

• 不要な重複 — 同じエンティティの複数のコピー。

Jira Cloud Migration Assistant の仕組み

Jira Cloud Migration Assistant は非破壊的であるように設計されているため、初めて移行する各エンティティのレコード (ワークフローやカスタム フィールドなど) を保存します。同じクラウド サイトへの移行が 2回目以降の場合、移行アシスタントはそのエンティティのレコードがすでにあるかどうかを確認します。

• 移行に含まれるエンティティがクラウド サイトにあるものと同じ名前を持っていて、その移行に関連するレコードがある場合は、移行先のサイト内の既存のエンティティにデータをリンクします。このエンティティは再移行されません。

• 移行に含まれるエンティティがクラウド サイトにあるものと同じ名前を持っていて、その移行に関連するレコードがない場合、重複やデータ損失を防ぐため (同じ名前を持つフィールドが確実に同じフィールドであると保証することはできないため)、名前に (移行済み) を追加して変更します。たとえば、カスタム フィールド A というエンティティは移行後、カスタム フィールド A (移行済み) に名前が変更されます。

ソリューション

重複

移行の実施時に、構成エンティティを重複させる必要がある場合があります。異なるスコープ/サーバー インスタンスからデータを移行する場合など、 重複が有益なケースもあります。 重複があると、同じ名前だが基礎のプロパティが異なるエンティティがマージされるのを防止できます。

サーバーでの内容

クラウドで見る可能性がある内容

重複したエンティティには、サイトで「(移行済み), (移行済み 1), (移行済み 2)」などのフラグが付けられます。 destination フラグの内容は、この挙動による影響を受けた移行の数によって決まります。 重複が多いと (例: 各カスタム フィールドに 20 個の重複) があると、パフォーマンス上の問題が発生する場合があります。

考えられる重複の原因

さまざまな理由によって、1 つのエンティティに対して複数の重複が作成される場合があります。これらは、カスタム フィールド A (移行済み)、カスタム フィールド A (移行済み 2)、カスタム フィールド A (移行済み 3) のように表示されます。

重複は、以下の理由により発生する可能性があります。

• 同じ名前のエンティティが複数のサーバーまたは Data Center インスタンスから 1 つのクラウド サイトに移行されている

  テスト サーバー インスタンス

  ユースケースの例の 1 つとして、お客様が本番サイトをサーバーのテスト インスタンスにクローンしている場合があります。このテスト インスタンスはスタンドアロンで独自の server-id を持つため、論理的にはまったく異なるサーバー インスタンスです。その後、テスト インスタンスから宛先のクラウドへの移行を試行すると、すべての設定エンティティが移行されます。

  テストが完了したら、移行済みのプロジェクトをクラウド サイトから削除しますが、プロジェクトを削除しても構成データが削除されるわけではありません。次回の移行試行時 (例: サーバーの本番環境インスタンスからの本番実行) に、JCMA は既存の重複を確認しないため、すべての設定データが重複されます。

  複数のサーバー (クラウド) インスタンスを 1 つのクラウド インスタンスに統合

  上述のシナリオに似ていますが、複数のサーバーから移行しようとした場合、JCMA では他のサーバーから移行されたエンティティを確認することはできないため、各要素が重複されます。これは意図的なものです。

• クラウドにデフォルトで存在するエンティティで、サーバーの移行プランにも含まれるもの

  この例はすべての移行に影響します。Jira サーバーおよびクラウドの新しいインスタンスには、既定で存在する Jira の既定のエンティティがあります。これらのエンティティがクラウドとサーバーの両方のインスタンスに存在する場合、現時点で既存の既定のエンティティを確認するメカニズムはないため、それらはサーバー インスタンスからクラウドに移行されます。

• まず Jira サイト インポート、次に同じサーバーまたは Data Center インスタンスから Jira Cloud Migration Assistant を使って段階的にデータを移行することで、共有構成エンティティの重複が生じます。

• カスタム フィールドの場合、 以下のいずれかが該当すれば重複する可能性があります。

  • フィールドのデータ タイプが異なる

  • フィールドの説明が異なる - 少しでも説明文が異なれば、そのフィールドは一致しないものとして扱われます。

  • フィールドのフィールド コンテキストが異なる

重複を防ぐために考えられる回避策

1. 複数の Server インスタンス (本番環境のミラーなど) からテストを行う場合に重複を防ぐ最も簡単な方法は、非本番のテスト用 Cloud 環境を使うことです。これにより、Cloud の本番環境インスタンスのコンテンツに影響を与えたり、テストによって複数の重複を発生させたりすることなく、任意の数のサーバーからのテストを行うことができます。これが特に 重要 となるのは、Cloud インスタンスに既存のデータがある場合です。このような重複エントリを体系的にクリーンアップする文書化された方法は存在しないためです。

   1. 新しいテスト実行用に重複をワイプするには、サイトを完全にリセットし、新しいサーバーから移行を再度開始します。

2. 複数のサーバー インスタンスからの統合を行う必要がある場合、重複を防ぐ方法の 1 つに、移行アシスタントで移行する前にサーバー インスタンスを統合する方法があります。この方法は常に利用可能なものではないのではかと思います。このため、複数のサーバー インスタンスから同じ宛先クラウドに移行する必要がある場合、発生する重複を確認するためにテストを行っていただくことを推奨します。

エンティティの変更を追跡する

移行の間隔が長くなると、エンティティが削除されたり変更されたりする可能性が高くなります。Jira インスタンスの統合を行っていて段階的なアプローチを執る必要がある場合は、クラウドとサーバーの両方で Jira の管理者コンソールにアクセスできる人を最小限に留め、完全な移行が完了するまでは共有エンティティの変更をフリーズするとチームに周知することを推奨します。これは Jira インスタンスの権限管理を通じて行えます。

さらにヘルプが必要ですか?

すべての推奨事項を確認したが、引き続きエラー メッセージの内容が不明な場合は、弊社のサポート チームに支援を依頼してください。