パイプラインの品質ゲート設計 テストと成果物管理を自動化する

DOP-C02では、パイプラインを組めることに加えて「壊れたものを本番へ通さない仕組み」をどう作るかが問われます。この記事では、テストの配置、成果物の管理、承認の入れ方を要件から設計できるようにします。

覚え方は「止める・残す・通す」の3つの観点です。どの段階で自動的に止めるか、成果物と証跡をどこに残すか、どこで人が承認して通すか。この3点がそろって初めて統制の取れたパイプラインになります。

止める：段階ごとの品質ゲート

テストは早いほど安く直せます。CodeBuildのbuildspecの中でユニットテストと静的解析を実行し、失敗したらビルドを落とすのが最初のゲートです。カバレッジしきい値やLintの警告数をコマンドの終了コードに反映させれば、それがそのまま品質ゲートになります。

インフラ側も同様です。CloudFormationならcfn-lintとChangeSetの差分確認、さらにCloudFormation Guardでポリシー違反（暗号化されていないS3バケットなど）を検出して落とします。「本番反映前に構成ポリシー違反を機械的に弾きたい」ならGuardが正解です。

残す：成果物とトレーサビリティ

ECRのタグイミュータビリティを有効にすると、同じタグで中身だけ差し替わる事故を防げます。「検証したイメージと本番で動くイメージが同一であることを保証したい」という要件では、イミュータブルタグかダイジェスト指定が答えになります。

通す：手動承認とマルチアカウント展開

本番ステージの前にCodePipelineの手動承認アクションを置き、SNSで承認依頼を通知します。承認者はIAMで限定し、承認の記録はCloudTrailに残るため統制の証跡になります。開発・ステージング・本番をアカウント分離している場合は、パイプラインを持つアカウントからクロスアカウントのIAMロールを引き受け、アーティファクトS3とKMSキーを共有する構成が定番です。

チェックリスト

• buildspec内でテスト失敗をビルド失敗に反映できる
• cfn-lintとCloudFormation Guardの役割の違いを説明できる
• ECRのイミュータブルタグで防げる事故を説明できる
• CodeArtifactで依存関係を統制する意義を理解している
• クロスアカウント展開でのS3とKMSの権限設計を説明できる

まとめ

品質ゲートは「止める・残す・通す」の3点で設計します。自動で止め、証跡を残し、人が通す境界を明示するのが要点です。仕上げに クイズ で知識を定着させ、出題範囲の最新版は AWS認定 公式ページ で必ず確認してください。