デプロイメントの承認
概要
デプロイメント要求の承認は、デプロイメントワークフローにおける認可のステップです。承認者は、要求者がデバイスへデプロイしようとしている内容を確認し、現在稼働している内容と比較したうえで、定められた期間に限って承認するか、または却下します。
承認自体では何もデプロイされません。デプロイメントの実行を許可するだけであり、その許可は承認期間が満了するまでに限られます。あるデバイスで誰が承認できるかは、そのデバイスが属するリソースグループの権限によって決まります。
ワークフローの要求者側については、デプロイメントの要求を参照してください。
新しい要求の通知
自分が承認できるデバイスで要求が起票されると、Deployments 通知カテゴリで設定されたチャネルを通じて通知されます。通知からは該当の要求へ直接アクセスできます。
未処理の要求はデバイスからも確認できます。デバイスを開き、Deployments タブを選択して Requests に切り替えてください。
実際に自分が担当しているデバイスについてのみ通知を受け取るには、デバイスヘッダーのベルアイコンを使用して、各デバイスごとに通知設定を行ってください。通知を参照してください。
要求の確認
要求を開くと、判断に必要なすべての情報を 1 つの画面で確認できます。
ヘッダーにはタイトルと Requested ステータス、そして Approve および Deny のアクションが表示されます。その下には、要求者、対象デバイス、プロジェクト、デプロイ対象のバージョン、要求の作成日時が記録されています。
確認作業は Changes タブで行います。
- Description – 変更内容に関する要求者の説明。
- Changes on the device – バージョン間で Modified および Unchanged となったオブジェクトの件数。
- Deployed version → Target version – 現在デバイス上にあるバージョン、そのデプロイ日時、それをデプロイしたデプロイメントジョブと、この要求でデプロイされるバージョン。
- Operation mode after deployment – デプロイ後にデバイスを Stop Mode または Run Mode のどちらに設定するか。
- プロジェクト内のパスによる変更オブジェクトの一覧（例:
Program / Scan / MAIN / ProgPou）。 - Compare – 2 つのバージョンの完全な並列比較を開きます。
Activity タブには要求の履歴が表示されるため、すでに判断が行われているかどうかを確認できます。
なお、対象バージョンはデプロイ済みバージョンより必ずしも新しいとは限りません。要求は意図的にデバイスを以前のバージョンへロールバックする場合もあり、デプロイ済みバージョンと対象バージョンの比較によってそれが可視化されます。
要求の承認
Approve を選択します。ダイアログでは承認期間と任意のコメントの入力を求められます。
| 項目 | 説明 |
|---|---|
| Approval valid until | デプロイメントを実行できる期間の終了時刻。既定値は現在から少なくとも 1 時間後の次の正時で、それ以降の任意の時刻に設定できます。 |
| Comment | 任意。要求の Activity タブに記録され、要求者から参照できます。 |
Approve で確定します。要求は Approved に移行し、要求者に通知され、Expires at に選択した時刻が設定されます。これにより要求者はデプロイメントを実行できるようになります。
その時刻までにデプロイメントが実行されなかった場合、要求は失効し、使用できなくなります。新たに要求を起票し、再度承認を得る必要があります。
承認期間の選択
承認期間は、変更を合意されたメンテナンス枠に結び付けるための手段です。期限を設けずに開放したままにするのではなく、メンテナンス枠の終了時刻に合わせて設定してください。そうすることで、今日付与した承認が数日後の予定外のタイミングでのデプロイに使われることを防げます。
要求の却下
要求を却下するには Deny を選択します。要求は Denied に移行し、実行できなくなり、要求者に通知されます。コメントを使って何を修正すべきかを説明し、要求者が修正した要求を起票できるようにしてください。
監査証跡
すべての判断は要求上に記録されます。誰が承認または却下したか、その日時、残されたコメント、設定された承認期間が記録されます。Activity タブには、作成から判断、実行までの完全な履歴が保持されます。Jobs 配下の実行ログと合わせて、デバイスへの変更を誰が認可し、実際に何がデプロイされたかというエンドツーエンドの記録が得られます。
ユースケース
- 本番設備に変更が適用される前に、四つ目の原則（ダブルチェック）を徹底する。
- 提案されたデプロイメントに、意図した変更のみが含まれていることを確認する。
- 認可されたデプロイメントを、合意されたメンテナンスウィンドウ内に限定する。
- 要求者と監査記録の双方に残る書面の理由を付けて変更を却下する。
- 監査時に変更管理要件への準拠を証明する。
詳細情報
- デプロイメントの要求 — 要求の起票と実行。
- デプロイメント — デプロイメント履歴と実行ログ。
- 通知 — デプロイメント通知の設定。