ステージングで変更の開発と検証を行う
ステージングで設定を変更する
次に、特定された要件を満たすため、ステージングで必要な項目 (カスタム フィールド、ワークフロー、スキームなど) を変更します。
これらの変更を内部で検証し、他のプロジェクトに与える影響を分析する
新しい設定を見直して検証します。提案された変更の複雑性と範囲に応じて、以下を確認することが重要となる場合があります。
- ワークフローが、すべての必要な状態およびトランジションで完了している。
- 課題には、すべての必須情報を含むフィールドがあります。
- すべての課題で、すべての必須フィールドが、入力時またはワークフローのいずれかの時点で入力されている。
- 全員に、タスクと責任に合った権限が供与されますが、それ以上の権限は付与されません。
- エンド ユーザーが表示できるよう、すべての画面が検証済である。
- すべての主な使用事例が検証済 - 必要な情報を取得するための一般的な課題の作成/トランジション/編集、フィルター、ダッシュボード、またはレポートの使用。
これらの変更が他のプロジェクトに与える影響に、特に注意を払うことが重要です。複数のプロジェクトと共有される設定オブジェクト (例: ワークフロー スキーム) を変更した際に、このような影響が発生します。ほとんどの場合、Jira では、設定オブジェクトがどこで使用されているかを確認できます。次の画像はワークフロー スキームの管理ページを示しています。ここで、各アクティブ ワークフロー スキームをどのプロジェクトが使用しているかを確認できます。
設定オブジェクトが変更され、他のオブジェクトで使用されていることがわかったら、そのオブジェクトにおける変更の影響を分析し、上記のレビューとテストのいくつかを実行する必要があります。最も複雑な状況は、変更案が他のプロジェクトと互換性がないことがわかり、それらにおける影響が許容されない場合です。その場合は、変更対象の設定オブジェクトをコピーしてそのコピーのいずれかを変更し、それ以外 (他のプロジェクトで使用されるオブジェクト) をそのままにしておく方法が最適です。
注: 変更を本番環境へ実装する際、スマート カスタム フィールド コンテキスト オプションが有効になっている場合は、他のプロジェクトに影響するカスタム フィールド変更を無視してもかまいません。
ユーザーとともに変更を検証する
ステージングですべての変更が実装されると、ユーザーに表示し、まとめてレビューを実施できます。目標は、ユーザーが新しい設定を表示して承認し、望ましい変更に関するフィードバックを収集できるようにすることです。
場合によっては、組織手順に従い、このユーザー受け入れが必須となります。
変更内容を把握する
おそらく、開発のどこかの時点で、本番環境の複製を作成してからどの設定が変更されたを自問することになるでしょう。この質問に実用的な答えを得るための方法が 2 つあります。
- ステージング インスタンスから構成をエクスポートし、本番へのシミュレートしたインポートを実行します。これにより、ステージングにおけるエクスポートしたプロジェクトの構成と本番環境の現在の構成との違いをすべて確認できます。
- ステージングで開発を開始する前に、プロジェクトの既存の設定をエクスポートして、結果の XML 構成ファイルを保存します。新しい開発の結果何が変更されたかを確認したい場合、新しい構成を別の XML ファイルにエクスポートして、開発が開始する前に取得したものと比較します。比較にはお使いの環境で利用可能なテキスト ファイルの diff ツールを使用でき、結果 XML ファイルは構成の変更の追跡に使用できるよう作られています。この方法は開発の異なるステージの XML ファイルを保存でき、それらをプロジェクト内で行われた構成変更の全体的な流れの「バージョン管理」として使用できるというメリットがあります。時折構成の変更を比較および表示したり、ステージング インスタンスの構成を、過去の構成のいずれかに復元することもできます (ステージングにその XML ファイルの構成をインポートします)。
💕 ご意見をお寄せください