開発者がコードを直して送ったら、あとは自動でテストされ、問題がなければ本番まで届く。深夜や週末に手作業でデプロイする必要がなくなる。CI/CDは、コードの変更からテスト、ビルド、デプロイまでを自動でつなげる仕組みです。
工場の自動検品ラインに近いものがあります。製品が流れてくるたびに機械が検査し、合格したものだけが次の工程へ進んで出荷される。人が毎回手で確かめなくてよいので、ミスが減り、速さも上がります。
コードを送ってから本番に届くまで
典型的な流れは次のとおりです。
- 開発者がコードの変更を Git のリポジトリへ送る
- 送られるたびに、自動でテストが走る
- テストが全部通ったら、動かせる形にまとめる（ビルド）。コンテナの形にまとめることも多い
- 確認用の環境（ステージング）へ自動でデプロイする
- 必要なら人の目で確認してから、本番環境へ届ける
前半の、変更を取り込むたびに自動でテストする部分が CI（継続的インテグレーション）、後半の、合格したものを本番の手前や本番まで自動で届ける部分が CD（継続的デリバリー、または継続的デプロイ）です。チームで同時に開発していても、互いのコードを混ぜたときの問題に早く気づけます。小さな変更を頻繁に届けられるので、一度の変更で壊れる範囲も小さくなります。
「テストが通った」は「壊れていない」ではない
検品ラインは、決められた項目しか検査しません。検査項目に漏れがあれば、不良品も合格して出荷されます。CI/CD も同じで、テストそのものの質が低ければ、「テストは通ったけれど壊れていた」ということが起こります。
自動化は人の判断を補うもので、代わりにはなりません。ラインを整えるのと同じくらい、何をテストするかの設計に手間をかける必要があります。
どこまで自動にするか
テストに時間がかかりすぎると、コードを送るたびに待たされ、開発の速さが落ちます。テストの速さも設計の対象です。
本番への自動デプロイは便利ですが、全部を自動にしなくてもかまいません。テストが通ってもすぐに本番へは行かず、確認のステップを挟む構成もよく使われます。自動で出すなら、問題があったときに素早く戻せるロールバックの仕組みと、届けたあとの状態を見張る監視をセットにしておきます。この流れ（パイプライン）の設定そのものもコードとして管理し、変更の履歴を残しておきましょう。