CI/CD：誰にでも分かりやすい基本概念の解説

はじめに

このブログは、CI/CD（シーアイ・シーディー）シリーズの第1回の記事です。

ソフトウェア開発が複雑化し、変更頻度が高まっている現状では、コードの品質を維持しつつ迅速にリリースすることが、多くの開発チームにとって大きな課題となっています。
この課題を解決するために、広く利用されているのがCI（Continuous Integration：継続的インテグレーション）およびCD（Continuous Delivery／Continuous Deployment：継続的デリバリー／継続的デプロイ） というプラクティスです。
本記事では、第一歩としてCIとCD の基本概念を分かりやすく解説します。開発フローの効率化を目指す方や、ツール導入前に全体像を把握したい方人に向けた入門記事です。

CI/CDとは？

CI（Continuous Integration）は、コードの変更を継続的に確認・検証する仕組みです。開発者がリポジトリにコードをプッシュすると、自動的にテストが実行され、正しく動作しているかどうかが検証されます。
この仕組みにより、開発者は早期にバグを発見し、効率的に修正を加えることができます。

例：開発者がコードを Git リポジトリにプッシュすると、CI サーバーが自動的にテストを実行します。
もしバグがあれば、以下のようなエラーメッセージが表示されます。

Running tests…
✔ UserServiceTest.testCreateUser
✘ UserServiceTest.testDeleteUser
Expected: status=200
Actual: status=500

→ NullPointerException が発生しました

1 tests failed.

この画面から確認できる内容：

• どのテストが失敗しているか
• 何が原因で失敗したのか（例：NullPointerException）
• 成功したテストと失敗したテストが一覧で確認できます。
• 修正すべき箇所が一目で分かります。

CD（Continuous Delivery）は、アプリを自動でサーバーに公開するしくみです。
CI がテストを実行し、「問題ありません」と なった後、CD はアプリを ステージング環境 や 本番環境 に送ります。

どうして CD が大切なのでしょうか？

• 手作業でのデプロイよりも安全です。
• ミスが少なくなります。
• コードの変更がユーザーにより早く届きます。
• 開発者はコードを書くことに集中できます。

例：developブランチからステージング環境へ自動デプロイ

• 開発者がdevelopブランチにプッシュします。
• CI がビルドとテストを実行します。
• OKならCD、が自動でステージング環境にデプロイします。
• QAチームが確認します。

まとめ

CI/CDの概要や役割については既に紹介しました。次の記事では、実際にCI/CDを運用するための 具体的なワークフロー例 や、GitHub Actions、GitLab CI、Jenkins など各種ツールの使い分け について詳しく解説します。

注釈

developブランチ：
新しい機能を実装したり、既存の機能を変更したりするためのブランチです。
開発中のコードが含まれています。

ステージング環境：
本番環境にデプロイする前に、アプリの動作をテストする場所です。「本番に近いテスト用環境」だとご理解ください。

本番環境：
ユーザーが実際に利用している環境です。アプリの正式な公開先です。

デプロイ（deploy）：
アプリをサーバー上に公開し、ユーザーが利用できるようにする作業です。

プッシュ（push）：
自分のパソコンのコードをGitリポジトリに送るということです。

ビルド（build）：
アプリのコードを一つにまとめ、実行可能な形にする作業です。
Java の場合、jarやwarファイルを生成することもあります。

参考資料: 

Continuous integration vs. delivery vs. deployment | Atlassian

What is CI/CD?