ひとことで言うと
CI/CDは、コードを変更したとき、テスト・ビルド・デプロイを自動でつなげて行う仕組みです。
CI（継続的インテグレーション）はコードを取り込むたびに自動でテストし、CD（継続的デリバリー／デプロイ）は合格したコードを自動で本番環境まで届けます。 手作業によるミスを減らし、変更を小さく素早く届け続けられるようにするための開発の仕組みです。
たとえ話でもう少し詳しく
CI/CDは、工場の自動検品ラインに近いです。
- 製品がラインに流れてくるたびに、機械が自動で検査する
- 検査を通過したものだけが次の工程へ進み、最終的に出荷される
- 人が毎回手作業で確認しなくてよいため、ミスが減り速度も上がる
開発でも同じです。 プログラマーがコードを変更してリポジトリに送ると、自動でテストが走ります。 テストが全部通れば、自動でビルドされ、本番サーバーへのデプロイまで進みます。 人が「今日デプロイしよう」と手順を踏まなくても、コードを送るたびに新しいバージョンが届く流れを作れます。
よく出る場面・使いどころ
- コードの変更が壊れていないかをプッシュのたびに自動確認したいとき
- 深夜や週末に手動でデプロイ作業をする負担をなくしたいとき
- チームで同時に開発していて、互いのコードが混ざっても問題ないか早めに気づきたいとき
- 小さな変更を頻繁に本番へ届けて、一度の変更リスクを小さくしたいとき
似た言葉との違い
- デプロイ
- 新しいコードを本番環境へ反映する作業そのもの
- CI/CDはそのデプロイを含む一連の流れを自動化する仕組み
- モニタリング
- デプロイ後のサービスが正常に動いているかを監視する仕組み
- CI/CDは届けるまでの自動化、モニタリングは届けた後の見張り役
- コンテナ
- アプリの実行環境をパッケージ化したもの
- CI/CDのパイプラインでコンテナをビルドし、そのままデプロイする構成がよく使われる
実務で気にするポイント
- テストが遅すぎるとコードを送るたびに待ち時間が増えるため、速さも意識する
- テストが通ってもすぐ本番へ行かず、確認ステップを挟む構成にすることも多い
- 本番への自動デプロイは便利だが、問題があったときに素早く戻せる仕組みも必要
- パイプラインの設定自体もコードで管理し、変更履歴を残す
注意: CI/CDが整っていても、テストの品質が低ければ「テストが通ったけど壊れていた」という事態は起きます。自動化は人の判断を補うものであり、テスト設計そのものへの投資も同じくらい大切です。