CI/CDとは？継続的インテグレーション・デリバリー・デプロイの違い

CI/CDは、コードの変更を統合して確かめ、利用できる状態へ届けるための取り組みです。CIは継続的インテグレーション、CDは継続的デリバリーまたは継続的デプロイメントを指します。

この二つのCDを区別すると、「テストを自動化したい」のか「本番公開まで自動化したい」のかを話し合いやすくなります。この記事では、開発・運用・依頼側の共通理解に必要な違いを整理します。

CIは変更を早く統合して確かめる

CIでは、コード変更を共有リポジトリへ頻繁に統合し、ビルドやテストを通して問題を見つけます。長期間分かれていた変更を最後にまとめるのではなく、変更が小さい段階で確認する考え方です。Red Hat「CI/CDとは」

自動テストを置いただけで、チームの統合方法まで決まるわけではありません。いつ変更を統合し、失敗した確認を誰が調べ、次の変更をどう扱うかを決めます。

たとえば、計算処理の修正で既存テストが失敗した場合に、そのまま別の変更を重ねるのか、先に原因を確認するのかを共有します。CIの結果を、単なる実行履歴ではなく次の行動につなげるためです。

CDには二つの意味がある

継続的デリバリーと継続的デプロイメントは、本番へ出す段階の扱いが異なります。

この区別はRed Hatの説明に基づきます。CI/CDという言葉を使っただけで、すべての変更が無条件に公開されるわけではありません。対象にする変更と、通過させる検査を確認してください。

自動化する範囲をチームで共有する

CI/CDを導入する際は、用語だけでなく、現在の工程のどこを自動化するかを示します。「コード取得→ビルド→テスト→試験環境→本番」という流れに、手動作業と自動作業を印す方法があります。

GitHub Actionsの例では、イベントをきっかけにワークフローが動き、ジョブやステップとしてビルド・テスト・デプロイなどを実行できます。これは実装手段の一例であり、CI/CDという考え方と特定製品は同じものではありません。GitHub「Understanding GitHub Actions」

自動化する対象は、繰り返す頻度だけでなく、合否を確かめる方法があるかで検討します。テストの対象を選ぶ際は、ソフトウェアテストの自動化を参照できます。

仮例：本番公開の手前に確認を残す

架空の社内申請システムで、変更ごとにビルドとテストを実行し、合格した版を試験環境で確認できるとします。本番へ出す日時は業務担当と調整し、担当者が公開操作を行うなら、継続的デリバリーとして説明できます。

さらに、本番反映も定めた検査の合格後に自動で行う設計へ進めるなら、継続的デプロイメントの範囲になります。その際も、確認する条件や公開後の監視が不要になるわけではありません。

どちらが常に優れているというものではなく、変更の性質と、失敗を検出・復旧できる仕組みに合わせて範囲を決めます。

まず小さな変更を一つ通す

最初に、何を変更し、どの検査を通り、誰が結果を見て、どの版が公開されたかを一つたどってください。手作業が残っている場所や、結果を見ても次の行動が決まらない場所が分かります。

そのうえで、自動化する工程と本番へ出す条件を言葉にします。具体的な成果物と停止条件の設計は、CI/CDパイプラインの設計で整理しています。