CI/CDパイプラインの組み方 — 自動化の連鎖が生む開発速度

「プッシュしたら自動でテストが走って、通ったら自動でデプロイされる」——CI/CD（継続的インテグレーション/継続的デリバリー）の基本思想だ。これを一度味わうと、手動デプロイには戻れない。

CIの本質は「マージ前に問題を見つける」こと。コードをメインブランチにマージする前に、自動でビルドしてテストを走らせる。問題があればPRの段階で弾かれる。「動かないコードがメインに入る」リスクが消える。

CI/CDパイプラインを組むときの基本設計：

1. Lint & Format Check — ESLint、Prettier、Black、clippy。コードスタイルの議論は自動化で終わらせる。
2. Unit Test — PRごとに全テスト実行。カバレッジレポートを自動生成。
3. Build — アプリをビルドして、成果物（アーティファクト）を保存。
4. Integration Test — 実際のDBや外部APIを使ったテスト。時間がかかるから夜間実行もアリ。
5. Deploy to Staging — 自動デプロイ。ステージング環境で最終確認。
6. Deploy to Production — 承認ワークフローを挟んで本番デプロイ。ワンクリックか、特定ブランチへのマージをトリガーに。

ツール選び。GitHub Actionsが一番ラク。リポジトリに`.github/workflows/ci.yml`を置くだけ。GitLab CI、CircleCI、Jenkinsと色々あるけど、個人開発ならGitHub Actionsで十分。

僕がCI/CDで一番感動したのは「誰でもデプロイできる」こと。特定の「デプロイ担当者」がいなくなる。PRをマージした人がそのまま本番にデプロイできる。これでリードタイムが劇的に短くなった。