Jira の課題やプロジェクトの過去のキーの移行
状況/問題
課題を別のプロジェクトに移動したりプロジェクトの名前を変更したりすると、課題キーが変更されます。ただし、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 つのキーが同時に存在することは許可されません。
考えられる競合のシナリオとそれらの解決方法についての詳細なブレイクダウンです。
プロジェクト
サーバーでのキー | クラウドでの状態 | 優先対象 | 詳細 |
---|---|---|---|
アクティブ | 存在しない | N/A | 競合がないため、プロジェクトは移行されます |
アクティブ | アクティブまたは履歴として存在 | N/A | 移行は許可されず、事前チェックでブロックされます |
履歴として存在 | 存在しない | N/A | 競合はないため、過去のキーが移行され、クラウドのアクティブなプロジェクトの過去のキーとして扱われます |
履歴として存在 | アクティブまたは履歴として存在 | クラウド | サーバーにあった過去のキーは無視されます。 移行後、このプロジェクト キーはこれまでと同様に、クラウドでのアクティブなバージョンまたは履歴バージョンを指します。 |
課題
サーバーでのキー | クラウドでの状態 | 優先対象 | 詳細 |
---|---|---|---|
アクティブ | 存在しない | N/A | 競合がないため、課題は移行されます |
アクティブ | アクティブ | N/A | 移行は許可されず、事前チェックでブロックされます。 この状況は、クラウドに同じプロジェクトが存在することを示します。 |
アクティブ | 履歴として存在 | Server | アクティブなバージョンが優先されます。 移行後、この課題を指しているリンクでクラウドのアクティブなバージョンへのリダイレクトは行われなくなり、移行された、サーバーのアクティブなバージョンをレンダリングするようになります。 |
履歴として存在 | 存在しない | N/A | 競合はないため、過去のキーが移行され、クラウドのアクティブな課題の過去のキーとして扱われます |
履歴として存在 | 履歴として存在 | クラウド | サーバーの過去のキーが無視されます。 移行後、この課題キーはこれまでと同様に、課題のクラウド バージョンを指します。 |
履歴として存在 | アクティブ | クラウド | サーバーの過去のキーは既存のアクティブなクラウド バージョンでシャドーされます。 前の例との違いとして、サーバー側の過去のキーは現在のサーバー課題の履歴としてインポートされます。ただしこれは、それをシャドーしているアクティブな課題またはアクティブなプロジェクトを削除するまでは無効化されたままになります。 |
今後の予定
上記で説明した競合の解決ロジックはほとんどの移行シナリオの要件を満たすと考えていますが、状況によっては移行後にリンクが変更される場合やされない場合があります。
今後は移行ロジックにさらなる柔軟性を提供し、競合の解決においてサーバーとクラウドのどちらを優先すべきかをユーザーが選択できるようにすることを予定しています。