デプロイの承認
概要
デプロイ要求の承認は、デプロイワークフローにおける認可のステップです。承認者は、要求者がデバイスへデプロイしようとしている内容を確認し、現在稼働中の内容と比較したうえで、定められた期間に限って承認するか、または却下します。
承認自体は何もデプロイしません。デプロイの実行を許可するだけであり、その許可は承認期間が満了するまでの間のみ有効です。あるデバイスで誰が承認できるかは、そのデバイスが所属するリソースグループの権限によって決まります。
ワークフローの要求者側については、デプロイの要求を参照してください。
新しい要求の通知
承認可能なデバイスで要求が起票されると、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 配下の実行ログと合わせることで、誰がデバイスへの変更を認可し、実際に何がデプロイされたかについてのエンドツーエンドの記録が得られます。
ユースケース
- 本番設備に変更が適用される前に、四つの目の原則（ダブルチェック）を徹底する。
- 提案されたデプロイに、本来含まれるべき変更のみが含まれていることを確認する。
- 認可されたデプロイを、合意済みのメンテナンスウィンドウ内に限定する。
- 要求者と監査記録の双方に残る書面上の理由を付けて変更を却下する。
- 監査時に変更管理要件への準拠を証明する。