Jira プロジェクトを移行する

Botron を使用してデータを移行する

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

このページで説明している内容は、Jira の標準機能ではありません。これらを実行するには、サードパーティ アドオン "Configuration Manager for Jira" をインストールする必要があります。

概要

このドキュメントでは、プロジェクトを Jira サーバ インスタンス間で移動させる際のベスト プラクティスについて説明します。ここで説明される移行プロセスは、Configuration Manager for Jira アドオンを使用して実行します。このページの手順は、Jira プロジェクト以外に、複数の Jira インスタンスのマージなどの統合操作に使用できます。


定義

このドキュメントの説明では、次のように定義します :

  • 開発 : 自由な環境または多くの環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。

  • ステージング : プロダクションの前のステージの環境。システム管理チームは運用開始前に正確な手順を確立できる。ステージングは本番環境のクローンまたは本番環境に近いレプリカにする必要があります。 

  • 本番環境 1 (ソース): プロジェクトの元となるライブ インスタンス。最小限のダウンタイムと十分なテスト済みの変更を要求します。
  • 本番環境 2 (ターゲット) プロジェクトの移動先となるライブ インスタンス。最小限のダウンタイムと十分なテスト済みの変更を要求。
  • 設定スナップショット は Configuration Manager for Jira アドオンを使用して作成され、Jira 設定オブジェクト の状態と、その時点での互いの関係を表します。2 種類の設定スナップショットがあります。


アーキテクチャ戦略に関する推奨事項

データ

このガイドは、透明性のあるエンドツーエンドの移行をデータを失うことなく実行する方法を示します。データ オブジェクトの大半は、Configuration Manager for Jira のデフォルト設定で処理されます。すべての例外と、それらの処理方法については、本ガイドの制限事項セクションをご参照ください。

プロセス

ソース (本番環境 1) インスタンスとターゲット (本番環境 2) インスタンスの間でプロジェクトを移動すると、ターゲット (本番環境 2) インスタンスが変化します。テスト -> ステージング -> 本番環境の手順に従うことをお勧めします。移行の前に、大規模な分析を実施する必要があります。これらのアクティビティは、本ガイドの分析フェーズでグループ化されます。プロジェクトの移動プロセスと設定変更のロールアウト プロセスの主な違いは、最初のシナリオではユーザーが生成したデータをすべて転送する必要があり、大規模なアップフロント分析が必要となるという点です。JIRA インスタンス間で複数のプロジェクトを移動するプロセスは、次の 4 つの主なステージで構成されます。

  • 分析 - この段階の間、プロジェクト構成間の競合とギャップが分析されます。「アプリケーションの移行仕様」を参照してください。
  • デプロイメント - このステージの間、移行手順ドキュメントを作成し、テスト サーバーでテストします。
  • ステージング - このステージの間、移行デプロイメント手順はステージング サーバーで分類/テストされます。
  • 本番環境 - このステージの間、移行デプロイメント手順を正式な本番環境で実施します。

 

計画

テスト - ステージング - 本番環境手順の使用事例で説明した、次の計画手順を、移行の前に実施する必要があります。

  • ステージング環境を準備し、同期された状態を維持する 
  • Configuration Manager for Jira のインストール
  • 変更リクエスト チケットで変更を追跡する
  • メンテナンス時間に、破壊的/非破壊的な変更を計画する 
  • コミュニケーション戦略の準備 

さらに、次の計画手順を含める必要があります。 

  • 両方の本番環境サーバーでバックアップを準備する 
  • ソース インスタンスとターゲット インスタンスの両方を確認し、検出された課題を修正します。システム ヘルス評価は Jira の整合性チェッカー および Configuration Manager for Jira の整合性チェックで実行する必要があります。

ステージ

第 1 段階: 分析

ステージ 1 の概要:

Jira インスタンス: 本番環境 1 (または複製)、テスト サーバ (本番環境 2 の複製)
目標: Application Migration Specification (AMS) ドキュメントの準備
ユーザー: Jira システム管理者、AD 管理者、DBA
必要なツール:  Configuration Manager for Jira

推奨される分析のリストを以下に示します。注: 変更が必要な場合は、AWS ドキュメントに含める必要があります。

  1. アドオンとバージョン

    Prod 1 サーバーとテスト サーバーの両方が次の要件を満たす必要があります。

      • 同じ Jira バージョンを実行している
      • バージョンが一致する同じアドオンのセットがある

  2. ユーザー管理の正規化

    両方の本番環境サーバーが外部ユーザー ディレクトリを使用している場合、両方のサーバーでユーザーとグループが完全一致する必要があります。一致が完全でない場合、分析を実行いてギャップと競合を特定する必要があります。 

    tip/resting Created with Sketch.

    例

      1. ギャップ:Prod 1 では、Jane Smith のユーザー名は jsmith ですが、 Prod 2 サーバーでは、彼女の名前は jane.smith
      2. 競合: 両方のサーバーには、ユーザー「Jonh Smith」とユーザー名 jsmith がいますが、ユーザー名は 2 人の異なる人物に対応しています。

    同様の課題がユーザー グループに適用されます。

    一般的に、競合と潜在的な一致のリストを準備し、ビジネス ユーザーはそれらの解決方法に関する情報を提供する必要があります。

    警告

    ユーザー管理が標準化されていない場合、広範囲にわたって悪影響が発生します。ユーザーまたはグループが使用されているすべてのフィールド (担当者、報告者) などに、間違ったユーザーまたはグループが含まれている可能性があります。ユーザーやグループを使用するすべての構成オブジェクトが正しく設定されない可能性があります。これには、権限、通知、ワークフロー、ユーザーとユーザー グループ フィールドのカスタマイズ、フィルターとダッシュボードの所有権、アジャイル ボード管理者、ユーザーまたはユーザー グループ フィールドを使用する JQL フィルター、課題セキュリティ スキームなどがあります。

    ギャップと競合の解決方法
    ギャップと競合に対する一般的なアプローチは、Prod 1 または Prod 2 サーバーのユーザー名を変更して一貫性を確保することです。名前の変更は、ユーザー管理 Crowd、AD、LDAP に使用するソリューションに応じて異なります。

  3. 「As is (現状のまま)」戦略

    ほとんどの場合、課題およびプロジェクト設定は、変更されずに "現状のまま" 新しい本番環境サーバに移動されます。変更がある場合、両方の Jira インスタンスの一貫性を確保するために変換が必要となります。このプロセスは移行を大幅に複雑なものにし、多くの時間が必要になります。また、AMS ドキュメントに含める必要があります。このガイドでは、"現状のまま" 移動する方法について説明します。変換を伴う移行プロセスの詳細は、Botron のサーバー チームにお問い合せください。

    tip/resting Created with Sketch.

    例

    バグ課題タイプは 2 つのサーバー タイプの異なるワークフローの一部となる場合があります。その課題が含まれるプロジェクトを移動する際、ユーザーは 2 つのオプションのいずれかを選択する必要があります。「As is」事例では、さまざまなプロジェクトが同じ課題タイプに異なるワークフローを使用します。変換事例では、2 つのプロジェクトが同じワークフローを使用するため、すべてのソース データを変換して新しいワークフローに一致させる必要があります。

  4. 設定の競合とギャップ

    Prod 2 サーバー内に名前やキーが既に存在する可能性があるプロジェクトを移行する際は、Prod 1 サーバーでこれらの名前を変更することにより、この競合を解決する必要があります。カスタム フィールド、解決策、優先度、ワークフロー名およびスキームで同じことが発生する可能性があります。競合の完全なリストおよび解決策のマッピングは、AWS ドキュメントに含める必要があります。逆のシナリオは、Prod 1 および Prod 2 の 2 つのカスタム フィールドの名前が異なり、セマンティックが異なる場合にも可能です。この場合、移行中にマージする必要があります。

    tip/resting Created with Sketch.

    ヒント

    1. この設定競合やギャップの分析は、Configuration Manager for Jira の変更および影響分析機能で実行できます。移行の前に、Configuration Manager for Jira で変更と影響の分析を実施し、Jira インスタンスに適用される変更の影響の包括的な詳細を確認できます。この分析を行うことで、変更の影響を受けるプロジェクトを確認し、競合やギャップを特定して解決できるようになります。導入される変更とそれらに対応する競合及びギャップは、Jira メニューと同じ順序でタブにグループ化されます。

    2. この分析は、カスタム フィールドの使用率を最適化し、新しく作成するのではなく 2 つのシステム間で再使用できる優れた機会これにより、サーバーのパフォーマンスが大幅に改善します。

  5. 既定のスキーム

    移行されたプロジェクトによって Prod 1 サーバーで使用されているすべての既定スキームは変更する必要があります。既定スキームを変更するには: 
    1. 使用済の既定スキームをコピーします。
    2. 新しく作成されたスキームの名前を変更します。
    3. プロジェクトと新しいスキームを関連付けます。

  6. 品質戦略

    品質戦略を開発し、すべての利害関係者の合意を得る必要があります。推奨される品質戦略は、各段階のテスト計画と、移行後の修正計画で構成されます。
  7. テスト計画

開発段階 以下を検証するために一連のテストを実行する必要があります。

  1. フィルター - 課題の数、課題の順序、列のレイアウト
  2. ダッシュボード - レイアウト (列、行)、ガジェットとガジェットのコンテンツ
  3. Agile
    1. ボード ビュー (例: バックログ、アクティブスプリント)
    2. 課題、ランキング、エピック、バージョン、見積もり、タイム トラッキング データの集約
    3. クイック フィルター 
    4. スプリントの並べ替えとコンテンツ
    5. レポート
    6. プロジェクト <-> ボードの関連付け
  4. 課題
    1. アジャイル データ - スプリント、エピック リンク
    2. コメント
    3. 履歴
    4. フィールド値 - サード パーティ カスタム フィールド、タイム トラッキングと見積もりなど
    5. 課題リンク
    6. Confluence リンク
    7. Bitbucket リンク (ブランチ、コミット)
  5. セキュリティ
    1. プロジェクト - 異なるロールのロール メンバーシップ、アクセスおよび運用
    2. ボード、フィルター、ダッシュボード - 所有権および運用
  6. 操作 - ワークフローを通じたトランジション、課題の作成/削除/編集、コメントなど。

ステージング段階 - 開発段階からのテストをもう一度実施し、移行対象プロジェクトのユーザーによってユーザー受け入れテスト (UAT) が実施されます。

本番環境段階 - 開発段階テストのサブセットに加え、制限付きの UAT テストを実施します。一般的に、本番環境でこれらのテストを実行できる時間に関する制限があります。この時間制限は、本番環境段階が行われるメンテナンス時間に合わせます。

本番環境後の修正計画 - この計画は、本番環境で発生した移行後の課題を処理するように作られたて手順をカバーします。これには、応答や解決のための SLA が含まれます。 

ステージ 2: 開発

ステージ 2 の概要:

Jira インスタンス: 本番環境 1 の複製、テスト サーバ (本番環境 2 の複製)
目標: 移行手順ドキュメントの準備
ユーザー: Jira システム管理者、AD 管理者、DBA
必要なツール: Configuration Manager for Jira

各移行タスクを適切に文書化し、番号付きリストに配置します。これには、一貫して繰り返せるよう、入力データと十分な詳細を含める必要があります。

文書化の推奨アプローチは、タスクの構造と各タスクを実現するための手順です。

  1. AMS ドキュメントに含まれる各データまたは設定変更について、必要な手順を実行します。

  2. 本番環境 1 サーバーから移行されるプロジェクトを含めたプロジェクト スナップショットを作成します。これには、プロジェクト アジャイル ボード、フィルター、ダッシュボード及び課題に関連するすべてが含まれます。 

    課題サポートは引き続きベータ モードです。現在、Configuration Manager 5.0 で正式なサポートを提供しようと尽力しています。

  3. 設定スナップショットをダウンロードします。Jira 設定がチケット経由で追跡されている場合、スナップショットを適切なチケットに添付する必要があります。
  4. 構成スナップショットをテスト サーバーにデプロイし、提案された構成変更を評価します。
  5. 構成案の変更と影響が AMS と一致していることを確認する評価することは非常に重要です。
    1. AMS が一致しない場合は、手順 2 で行われた変更を修正絵する必要があります。本番 2 とテスト サーバーの複製でバックアップを復元し、手順 1 を再開します。
    2. AMS が一致する場合は、続行します。
  6. スナップショットのデプロイメントに必要なデプロイメント時間を使用してチケットを更新します。
  7. テスト ステージのテスト プランを実行する
    1. テストが失敗した場合は、解決する必要があります。本番 1 とテスト サーバーの複製でバックアップを復元し、手順 1 を再開します。
    2. テストに合格したら、移行チケットに移行手順を添付し、ステージ 3 に進みます。

このステージで説明した手順は複数回繰り返し、すべてがスムーズに動き、変更案と関連テストの両方が成功することを確かめる必要があります。 


ステージ 3: ステージング/QA

ステージ 3 の概要:

Jira インスタンス: 本番環境 1 (または複製)、ステージング サーバ (本番環境 2 の類似レプリカ)
目標: これは移行のグランド リハーサルであり、2 つの主な目標があります。

  1. 移行手順を検証し、UAT を実施します。
  2. 移行期間の正確な時間の見積もりを取得します。

ユーザー: Jira システム管理者、AD 管理者、DBA、UAT を実行するビジネス ユーザー
必要なツール: Configuration Manager for Jira

このステージの手順は次のとおりです。

  1. 変更を行わずに移行手順から各タスクを実行します。
  2. 必要なダウンタイムを見積もります。
  3. 開発ステージ テストを実行します。
  4. UAT テストを実行します。

  • 開発段階テストと UAT の両方が成功したら、ステージングの成功を宣言して本番環境に進みます。
  • 失敗した場合、課題のタイプに応じて、開発手順を変更、ステージングを繰り返す、または開発段階に戻って課題を修正します。

ステージ 4: 本番環境のデプロイメント

Jira インスタンス: 本番環境 1、本番環境 2
目標: 正式な本番環境 2 での移行の完了
ユーザー: Jira システム管理者、AD 管理者、DBA
必要なツール:  Configuration Manager for Jira

移行プロセスの 4 番目および最後の段階は、ステージング段階とほとんど同じです。主な違いは、本番環境のクローンではなく、実際の環境 1 および 2 サーバーで作業するということです。

このステージの手順は次のとおりです。

  1. 両方の本番環境サーバーの完全なバックアップを作成します。
  2. ユーザーのアクセスを本番 2 サーバーに制限します。
  3. 変更梨で取り込まれるよう、移行手順から各タスクを実行します。
  4. 開発ステージ テストを実行します。
  5. UAT テストを実行します。
  6. 開発段階テストと UAT の両方が成功すると、移行が成功したことを宣言して、ユーザーへアクセスをオープンにします。
  7. 成功しない場合、見つかった課題のタイプに応じて 2 つのオプションがあります。
    1. 本番環境 2 サーバーに変更/修正を適用して UAT テストを返します。
    2. バックアップを復元し、課題が解決されるまで本番環境デプロイメントのスケジュールを再設定します。

制限と回避策

考慮すべき特定のシステム制限事項があります。

  • アドオン データ: 特定のアドオン カスタム フィールド設定、アドオン ワークフロー プロパティ設定。Jira 設定オブジェクト外のその他のアドオン データは含まれない場合があります。カスタム ソリューションを開発する必要があります。
  • Jira Service Desk: Jira Service Desk 固有の設定は OOTB ではサポートされません。Configuration Manager の将来のリリースで追加される予定です。

制限事項や、その他の既知の問題に関する回避策案:

  • スクリプト – Configuration Manager for Jira で処理されないデータを移行するために API レベルのスクリプトを開発できます。スクリプト開発には ScriptRunner アドオンを使用できます。
  • 手動 - 設定の量が少ない場合、ターゲット Jira に手動で追加できます。
  • プロフェッショナル サービス - Botron のソリューション アーキテクト チームは、あらゆるタイプのデータを移行するカスタム ソリューションを開発できます。

一般的な課題

デプロイメントの際に、データの携帯性プロセスに悪影響を及ぼす可能性がある、いくつかの一般的な課題を特定しました。これらの一般的な課題の例:

  • スナップショットの作成/デプロイメントの妨げとなる整合性チェック エラー。ターゲット/本番環境サーバーの整合性を保持するため。スナップショットを作成またはデプロイするたびに Configuration Manager 整合性チェック が実行されます。続行するには、報告されたすべての重大エラーを解決する必要があります。詳細は、こちらで入手できます。
  • Jira バージョンの違い - ソースとターゲットの Jira バージョン (特にメジャー バージョン) の違い。
  • アプリケーション権限 / ライセンス: 7.x の場合、デプロイメントを実行するユーザーがソフトウェア プロジェクトを作成する権限を持たない、または Jira Software アプリケーションがインストールされていない / ライセンスがない。
  • プロキシ/ファイアウォール: 大きなインスタンスでのスナップショットの作成時やデプロイ時の分析前に、問題となる可能性があります。それ以外の場合、デプロイメント自体に問題はありません。これは、プロキシ サーバーのタイムアウト限度を増やし、ファイアウォールのブロック ルールを無効化することで回避できます。

よくある質問

  1. 設定全体とすべての課題は、Configuration Manager for Jira を使用して自動的に本番環境に移動されますか?
    はい。設定スナップショットで取得されたすべての設定がロールアウトされます。同様に、選択したプロジェクトのすべての課題も同様です。Configuration Manager for Jira でサポートされない一部のアドオン設定やデータは移動されません。サポートされるオブジェクトはこちらに記載されています。
  2. 新しいサーバー インスタンスを使用しているサーバーへのプロジェクトを古いサーバー インスタンスへ移動することはできますか?
    両方の本番環境サーバーを同じバージョンにすることを強くお勧めします。そうでない場合、無駄な複雑性が追加されることになります。
  3. 複数のプロジェクトを移動させるにはどのくらい時間がかかりますか?
    ユーザー管理の正規化、データ量およびその他の分析によって異なります。数時間から数週間かかることがあります。
  4. Configuration Manager でカスタム アドオン データを移動させることはできますか?
    はい。Configuration Manager はあらゆるカスタム アドオンを処理するよう拡張できます。詳細は、Botron の サービス チームにお問合せください。

お困りですか?

自分で問題を解決できない場合、次の通信チャンネル経由でサポートまでお問い合わせいただけます。

最終更新日 2022 年 9 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.