証拠に基づいてリリースを判断する

判断を正確に示す

成功したパイプラインは、一連の確認から得た証拠です。リリースの判断全体を説明するものではありません。責任者は、何が、どこで変わり、どのような影響が残るかを知る必要があります。

架空の顧客エクスポートでは、受け入れたcommitと、そこから作った成果物を特定します。対象環境を示します。関連するテスト、レビュー、承認済みの例外へリンクします。アプリに伴うデータやインフラの変更も含めてください。

NISTのSSDFは安全な開発の実践を示し、SLSAの来歴情報は成果物の作られ方を説明する助けになります。どちらも、このサービスにこのリリースが適切かを判断する必要性をなくすものではありません。NIST SSDF、SLSAの来歴形式を参照してください。

mergeはソースの変更をブランチへ取り込みます。デプロイは成果物を環境へ配置します。機能の公開は、利用者がその動作を使えるようにします。同時に起こることはありますが、必ずしも同じ出来事ではありません。

無効化した機能をデプロイし、後で公開する場合があります。データベースの移行は、画面に機能が現れる前に本番へ影響することがあります。PRのmergeですべての影響を説明できると考えず、実際の順序を定めます。

エクスポートでは、feature flagで初期の公開範囲を制限できる場合があります。ただし、新しいエンドポイントを自動で保護したり、スキーマ移行を元に戻したりするわけではありません。影響が発生する箇所で、管理策を検証してください。

別の責任者が調べられる記録を使います。

主張は具体的にします。「テスト成功」だけより、リリース対象commitの結果へのリンクと、対象範囲の説明のほうが確かな証拠です。「ロールバック可能」だけより、限界を明示したテスト済み手順のほうが確かな証拠です。

実行前にリリース条件を定めます。架空のエクスポートでは、組織をまたぐアクセスが成功する、成果物が承認したダイジェスト値と異なる、復旧手段が使えない場合に停止します。これらは条件の例であり、万能のチェックリストではありません。

デプロイ後は、利用者に重要なシグナルを確認します。エラーの動作と応答時間を、合意したサービス目標と比較します。プロセスが正常でも、利用者の業務フローが動く証拠にはなりません。

条件を満たせない場合は、合意した対応を使います。機能の公開停止、互換性のあるコードのロールバック、データの復旧などが考えられます。より大きな障害を作らずに、今の障害へ対処できる操作を選びます。

実際にデプロイした成果物と結果を記録します。実行が計画と違った場合は、その差を明示します。インシデントと想定外の作業を、次のリリース設計に反映します。

自動化された提供システムは、この記録を確認しやすくするべきです。つながりのないチャット、ログ、スクリーンショットから、レビュー担当者がリリースを再構成しなければならない状態にしてはいけません。明確な証拠があれば、判断の責任を保ちながら、日常的な作業を自動化できます。