状況/問題

課題を別のプロジェクトに移動したりプロジェクトの名前を変更したりすると、課題キーが変更されます。ただし、Jira は過去のすべてのキーを保存しているため、リンク (過去のキーを参照) を使用して課題にアクセスしようとしたときにそのリンクは引き続き機能します。

これまで、Jira Cloud Migration Assistant ではこのようなキー履歴は移行されませんでした。これは、1.4.3 一般公開リリースで修正されました。サーバーとクラウドの両方のサイトで過去の課題キーの競合がある場合、競合を解決するための措置を移行中に行う必要があり、この仕組みについてご説明します。

問題点

クラウド インスタンスのプロジェクト ALPHA に所属する課題 ALPHA-1 が存在するとします。それは後に別のプロジェクト BETA に移動され、新しいキーは BETA-5 になりました。課題を移動する前に、ユーザーがリンクをどこかに保存している可能性があります (例: ブラウザでのブックマーク)。BETA-5 になったあとも ALPHA-1 への古いリンクは動作し、BETA-5 へのリダイレクトを行います。

次に、クラウドで ALPHA プロジェクトが存在しなくなり、完全に別の無関係のプロジェクトALPHA をサーバー インスタンスから移行することになったとします。このプロジェクトのキーも ALPHA-1 です。

クラウド インスタンスで ALPHA-1 の検索に対して返せる結果は 1 件のみであるため、ここで設計上の判断を行う必要がありました。このような場合、サーバーの ALPHA-1 バージョンを優先して競合を解決することにしました。これは課題の現在の/アクティブなキーであるため、エイリアスの履歴よりも優先されると考えました。
これにより、ALPHA-1 へのブックマークは、サーバーから移行された別の課題である ALPHA-1 を指すようになり、BETA-1 へのリダイレクトは行われなくなります。

あるいは、ALPHA-1 をご利用の Confluence Server インスタンスのページでブックマークしていて、これもクラウドに移行された場合、同じ競合解決ロジックが適用され、ALPHA-1 が移行後も正しい課題を指す、期待された挙動になります。

これは、競合の解決が要求される事例として考えられる多数のシナリオのうちの 2 つに過ぎません。このような競合の解決方法を理解しておくこと重要です。

競合の解決ロジック

簡単に説明すると、解決ロジックは次の 2 つのシンプルなルールに従います。

• 現在の (アクティブな) キーが過去のものよりも優先される

• 過去の 2 つのキーの間の競合はクラウド バージョンを優先して解決される

これまでと同様に、プロジェクトでも課題でも、2 つのキーが同時に存在することは許可されません。

考えられる競合のシナリオとそれらの解決方法についての詳細なブレイクダウンです。

プロジェクト

課題

今後の予定

上記で説明した競合の解決ロジックはほとんどの移行シナリオの要件を満たすと考えていますが、状況によっては移行後にリンクが変更される場合やされない場合があります。

今後は移行ロジックにさらなる柔軟性を提供し、競合の解決においてサーバーとクラウドのどちらを優先すべきかをユーザーが選択できるようにすることを予定しています。