4.2CI/CDとコンテナ

DevNet で問われるのは「CI/CD とは何か」という定義ではなく、目の前のパイプラインや Dockerfile が何を保証し、どこに欠陥があるかを読めることです。テストを通さずにデプロイするパイプラインは事故を量産し、キャッシュを無視した Dockerfile はビルドを無駄に遅くし、CMD を書き忘れたイメージは起動しません。この節では、CI/CD の各段階・Python のユニットテスト・Dockerfile の各命令を、提示された成果物を解釈・診断する視点で押さえます。

4.2.1CI/CDパイプライン

• CI（継続的インテグレーション）＝開発者の変更をこまめに共有ブランチへ統合し、その都度自動でビルドとテストを回して壊れを早期検知する。CD（継続的デリバリ/デプロイ）は、テストを通った成果物を自動で配布/本番反映まで進める。要は build -> test -> deploy を人手を介さず反復可能にする仕組み。
• パイプラインの要はテストが失敗したら先へ進めない（ゲート）こと。test ステージが赤なら deploy は実行されないのが正しい設計で、テストを飛ばして本番反映するパイプラインは自動化された事故になる。失敗を早く・小さく検知するほど修正コストは小さい。

4.2.2Pythonユニットテスト

• ユニットテスト＝関数やメソッドという最小単位の振る舞いを、入力に対する期待出力で自動検証する。Python では標準の unittest（assertEqual などのアサーション）や pytest（assert 文と簡潔な記法）を使う。CI が回すのは主にこのユニットテストで、変更が既存の振る舞いを壊していないかを守る。
• 良いテストは1つの振る舞いを1つのケースで確かめ、失敗時にどこがなぜ壊れたかが分かる。例えば assertEqual(add(2, 3), 5) が落ちれば add の回帰が一目で分かる。テストが通ることが CI の合格条件であり、テストが無いコードは CI の保護を受けられない点が実務上の要。