はじめに
CI/CDという言葉は、GitHub Actions や自動デプロイ周りでかなり頻繁に出てきます。
ただ、CIとCDがそれぞれ何を指しているのかは、意外と曖昧なまま使われることも多いです。
この記事では、その違いと役割を整理します。
CIとは
CIは Continuous Integration の略です。
日本語では「継続的インテグレーション」と訳されます。
簡単に言うと、
コード変更を自動チェックしながら継続的に統合する仕組み
です。
なぜ必要なのか
複数人で開発していると、いろいろな変更が同時に入ります。
機能追加、リファクタ、ライブラリ更新などが並行して進むため、コードをマージした瞬間に問題が起きることがあります。
例えば、
- テスト失敗
- 型エラー
- ビルド失敗
などです。
ローカルでは問題なく動いていても、他人の変更と組み合わさると壊れるケースは普通にあります。
CIでやること
CIでは、push や Pull Request をきっかけに、自動でチェックを実行します。
例えば、
- npm test
- npm run lint
- npm run build
みたいな処理です。
GitHub Actions や CircleCI が使われることも多いです。
Pull Requestを作るとどうなるのか
例えば GitHub Actions を設定している場合、Pull Request 作成時に自動でテストが実行されます。
PR作成
↓
自動テスト
↓
Lint確認
↓
Build確認
問題があれば、その時点で検知できます。
レビューする前に壊れているコードを見つけられるのが大きいです。
CDとは
CDは Continuous Delivery または Continuous Deployment の略です。
ここは文脈によって意味が少し変わります。
Continuous Delivery
Continuous Delivery は、
デプロイ可能な状態までを自動化する
考え方です。
例えば、
- テスト
- ビルド
- Dockerイメージ作成
までは自動で行い、最終的な本番反映だけ人が実行します。
Continuous Deployment
Continuous Deployment は、本番反映まで自動化します。
mainへマージ
↓
自動テスト
↓
自動デプロイ
↓
本番反映
まで全部自動です。
かなり便利ですが、その分テスト品質も重要になります。
CIとCDの違い
CIは、コード変更を安全に統合するための仕組みです。
CDは、リリースまでの流れを自動化するための仕組みです。
そのため、
CI → CD
の順で扱われることが多いです。
GitHub Actions
最近かなり使われているのが GitHub Actions です。
GitHub上でそのままCI/CDを構築できます。
例えば、
name: test
on:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install
- run: npm test
みたいに書くと、Pull Request作成時に自動テストできます。
CI/CDがあると何が変わるのか
CI/CDがない場合、
- 手動確認
- 手動テスト
- 手動デプロイ
がかなり増えます。
規模が大きくなるほど、手順ミスや確認漏れも起きやすくなります。
例えば、毎回SSHして手動デプロイする運用だと、
- デプロイ漏れ
- コマンドミス
- 環境差分
なども発生しやすくなります。
CI/CDを導入すると、コード変更からリリースまでの流れをかなり統一できます。
おわりに
CI/CDは、単なる便利ツールというより、開発フローそのものに近いです。
最近はGitHub Actionsだけでもかなり色々できるので、個人開発でも触る機会が増えています。
まずはテスト自動化だけでも入れてみると、かなりイメージしやすくなると思います。