構成の変更をステージングから本番に実装する

概要

「ステージングから本番環境へ設定変更を実装する」とはどういう意味でしょうか。

例をあげて説明しましょう。あなたが、数百のユーザーがいる JIRA インスタンスを担当する JIRA 管理者だと想定します。2 つの大きなプロジェクトに取り組んでいるユーザーが、これらのプロジェクトを JIRA 内でマージさせる方法を変更したがっています。JIRA チームは、これらの変更の実装には最低 3 営業日かかり、本番環境に配置するためにユーザーによって確認及び検証する必要があるということを把握しています。ユーザー要件の一部がはっきりとしておらず、あなたは、ユーザーが実際に実装を目にするまで、新しい実装が彼らの要望に沿っているか判断できないだろうとわかっています。要件の予備分析は、プロジェクト ワークフロー、画面、カスタム フィールド、および権限スキームに対する変更を示しています。権限を必要とするユーザーにのみ供与するため、新しいグループも作成されます。

これらの変更を本番環境へ実装し始めれば、JIRA ユーザーは、3 日間、部分的に実装された変更で我慢することになります。さらに、ユーザーが検証するまで変更は最終決定ではないため、変更とやり直しが数回繰り返される可能性もあります。つまり、影響を受けるプロジェクトのユーザーの日常業務が大幅に中断されることになります。そのため、あなたはすぐに、まず別の開発環境 (本ガイドでは「ステージング」と呼びます) でこれらの変更を実装する必要があるという点に気づきます。

この決定により、新しい質問が浮かびます。

  • ステージングで実行された変更を、手動で実行せずに本番へ移行するにはどうすればよいでしょうか?
  • ステージング内のテストと検証が、変更を本番環境へ移した際の最終結果を実際に反映していることを確認するにはどうすればよいでしょうか?

本ガイドでは、これらの質問に回答し、JIRA ガイドインスタンス間で変更を実施、確認、および実装するための推奨プロセスを提供します。このプロセスは、Project Configurator for JIRA と呼ばれるプラグインの仕様に基づいています。

より精巧なプロセス

場合によっては、本番環境に変更が適用される割合が非常に高く、異なるプロジェクトで頻繁に設定変更が行われる場合、本ガイドに記載されたプロセスでは、新しい設定が本番環境に与える影響の代表的なテストを保証できない場合があります。このような場合、追加 JIRA インスタンスを使用するプロセスのバリエーションを持つと実用的です。

このバリエーションで、変更を本番環境に適用する準備が整ったら、本番環境の複製が作成されます。これを、「プレ本番環境」と呼びましょう。変更はプレ本番環境にインポートされ、そこで新しい設定を評価し、必要に応じて修正します。次に、変更後のプロジェクトの新しい設定をプレ本番環境からエクスポートし、本番環境へインポートします。

明らかに、プレ本番環境へインポートする際には、実際の本番環境インスタンスへインポートする場合程の注意は不要です。そのため、以前のバックアップとインスタンスのロックアップは必要ありません。  

「構成」の概念に含まれるもの

これを説明する最善の方法は、設定のエクスポート/インポートで Project Configurator for JIRA が移動するエンティティのリストを示すことです。

プロジェクトのグループに設定をインポートすると、それらのプロジェクトで使用されているすべての設定がエクスポートされます。詳細は、エクスポートするオブジェクトの選択を参照してください。

制限事項

技術的な制約事項についてはこちらに記載されています。両方の JIRA インスタンス内で同時に発生する必要がある項目セクションの制限事項は、このガイドのアドバイスに従っている場合、問題ではありません。ステージング インスタンスを本番環境の複製として開始することで、療法のインスタンスのこれらの観点が同じであることを保証できます。

Cloud および Server インスタンス

このガイドで説明されるプロセスは、JIRA Server インスタンスにのみ有効です。変更を JIRA Cloud インスタンスに実装するために使用する場合は、次の手順で間接的にのみ実行できます。

  1. JIRA Cloud を Server インスタンスに複製し、ステージング マシンとして使用します (開発/テスト用)。これにより、本ガイドで説明した最初の手順を置き換えます。
  2. 本ガイドに記載されている残りの手順 (「ステージングから設定の変更をエクスポートする」まで) に従います。
  3. JIRA Cloud インスタンスのユーザー利用をロックします。
  4. JIRA Server インスタンスに複製します。これは、プロセスの次の手順 (設定のインポート結果の検証) で「本番環境」インスタンスとして動作します。
  5. When verification shows that promotion results are correct at the "production" Server instance, move it to the Cloud, replacing the previous Cloud instance.
  6. 新しい Cloud インスタンスをユーザーに解放し、通常の作業を再開します。

 

 

最終更新日 2018 年 5 月 8 日

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.