変更のたびに機械が自動でビルド・テストし、合格したら届ける仕組み「CI/CD」。CIがない現場で起きるマージ地獄から、パイプラインの流れ、失敗したらマージできないブランチ保護、CD、GitHub Actionsの設定ファイルとの対応まで、図が動く形で解説します。
CI/CDは、コードを変更するたびに、テストやデプロイ（本番への反映）を機械が自動でやってくれる仕組みのことです。CIは Continuous Integration（継続的インテグレーション）、CDは Continuous Delivery / Deployment（継続的デリバリー／デプロイ）の略です。
ここまでの章で、ユニットテスト、統合テスト、Dockerを見てきました。CI/CDは、それらを「人が忘れずに実行する」のではなく「変更のたびに必ず自動で実行される」ようにする、いわば土台の仕組みです。
CIがない現場を想像してみましょう。AさんとBさんが、それぞれ自分の作業ブランチ（メインのコードから枝分かれした作業場所）で3週間ずつ開発を進め、最後にまとめてメインに合流させようとします。
すると、二人が同じところを別々に書き換えていたり、片方の変更がもう片方の前提を崩していたりして、つないだ瞬間にあちこちが壊れます。これは「マージ地獄」と呼ばれ、どこから直せばいいのかも分からなくなりがちです。
CI（継続的インテグレーション）の考え方はシンプルです。変更を小さく保って、こまめにメインに合流させる。そして合流させるたびに、機械が自動でテストを流して、壊れていないことを確かめる。
一回あたりの変更が小さいので、ぶつかっても影響はわずかで、どこが原因かもすぐ分かります。図のように、長いブランチが短い往復に縮まり、合流するたびに緑の印（テスト合格）が付いていきます。
具体的には、開発者がコードをGitHubなどに送る（pushする）と、それを合図にCIのサーバーが動き出します。まずアプリをビルド（動かせる形に組み立てる）し、次にテストを実行し、最後にその結果を知らせてくれます。この一連の流れをパイプラインと呼びます。
人がやるのは「コードを送る」ところまでです。そこから先は、毎回同じ手順で、機械が抜けもれなく実行してくれます。上にあるオレンジの札が、あなたが送った変更です。
変更（オレンジの札）がパイプラインを進んでいきます。ビルドが終わり、いまはテストを実行しているところです。ユニットテストも、Dockerで本物のデータベースを起動して行う統合テストも、ここでまとめて流れます。
人が手で実行すると、急いでいるときに飛ばしてしまったり、手順を間違えたりします。CIなら、いつ誰が送った変更でも、必ず同じテストを通ります。
テストが全部合格すると、その結果がプルリクエスト（PR：「この変更をメインに取り込んでほしい」という依頼）に緑のチェックとして表示されます。
レビューする人は、少なくともテストは全部通っていることを確認したうえで、中身の確認に集中できます。「動くかどうか」は機械が、「これでいいか」は人が見る、という分担になるのです。
テストが一つでも失敗すると、プルリクエストには赤い印が付きます。さらに「ブランチ保護」という設定をしておくと、CIが合格するまでマージボタンが押せなくなります。
こうしておけば、壊れたコードがメインに入り込むことを仕組みで防げます。人の注意力に頼らない、というのがCIの大事なところです。
CIでテストに合格してマージされた変更を、そのまま自動でステージング（本番そっくりの確認用の環境）や本番に反映するのがCDです。人が手でサーバーに入ってファイルを置き換える必要はありません。パイプラインが右へ伸びて、変更が本番まで運ばれていきます。
ここで前の章のDockerが効いてきます。CIでテストしたのと同じイメージを、そのまま本番に置けば、「テストした環境」と「本番の環境」が一致します。
CIの手順は、たとえばGitHub Actionsなら、リポジトリの中にYAMLという形式のファイルで書きます。さっきまでのパイプラインの箱が、そのまま設定ファイルの行に対応しているのが分かるでしょうか。
「プルリクエストが来たら」「コードを取ってきて」「Dockerでデータベースを起動して」「ビルドして」「テストする」。人に説明するのとほとんど同じ順番で書けるので、思っているより難しくありません。なお actions/checkout@vX の vX には、公式の最新バージョンを指定します。
CIが本番と同じDockerイメージ、同じバージョンのデータベースでテストを流していれば、「CIで合格した＝本番でも動く」と、かなりの自信を持って言えるようになります。
そうなると、プルリクエストのたびに人がコードを一行ずつ読んで確かめる必要は、ぐっと減ります。次の最終章では、ここまでの道具を全部組み合わせて、テスト駆動開発でAIに開発を回させ、レビューまで自動化する方法を見ていきます。
