
CI/CDとは「コードを安全に届ける仕組み」
CI/CDとは「コードを安全に届ける仕組み」
コードを
- CI
(Continuous Integration:継続的インテグレーション) — コードの変更を 自動で テスト・検証する 仕組み - CD
(Continuous Delivery/Deployment:継続的デリバリー/デプロイ) — テストを通過した コードを 自動で 本番環境に リリースする 仕組み
なぜCI/CDが必要なのか
CI/CDがない場合の問題
手動で
- テストを
実行し忘れて、 バグのある コードが 本番に 出てしまう - 手動で
ファイルを アップロードする 際に、 手順を 間違える - 「自分の
PCでは 動くのに、 本番では 動かない」 問題が 起きる - デプロイ作業に
時間がかかり、 特定の 人しかできない
CI/CDがある場合のメリット
- コードを
プッシュするだけで、 自動で テスト・デプロイが 走る - 人的ミスが
減る - デプロイ作業が
属人化しない - リリースの
スピードが 上がる
CIの仕組み
CIで行われること
コードを
- コードの
ビルド — コードが正しく コンパイルできるか 確認 - リンターの
実行 — コーディング規約に違反して いないか 確認 - 自動テストの
実行 — ユニットテスト、結合 テストを 実行 - カバレッジレポート — テストがどの
程度の コードを カバーして いるか 計測
CIが失敗したら
CIが
CIが
- エラーログを
確認して、 何が 失敗したかを 特定する - 自分の
ローカル環境でも 同じ テストを 実行して 確認する - 修正して
再プッシュする (CIは 自動で 再実行される)
CDの仕組み
デプロイの流れ
CIをmainブランチに
| ステップ | 内容 |
|---|---|
| 1. ビルド | 本番用の |
| 2. テスト | 本番環境に |
| 3. ステージング | 本番と |
| 4. 本番デプロイ | ユーザーが |
デプロイ戦略
| 戦略 | 説明 | メリット |
|---|---|---|
| ローリングデプロイ | サーバーを | ダウンタイムなし |
| ブルー/グリーン | 新旧2つの | 切り戻しが |
| カナリアリリース | 一部の | リスクを |
CI/CDも
よく使われるCI/CDツール
GitHub Actions
GitHubに
- GitHubリポジトリに
.github/workflows/ディレクトリを作り、YAMLファイルで 設定を 書く - プッシュや
PR作成を トリガーにして、 自動で ジョブを 実行する - 無料枠が
充実しており、 個人プロジェクトでも 使いやすい
その他のツール
- CircleCI — 高速で
柔軟な 設定が 可能 - Jenkins — 歴史の
長い オープンソースツール。 大企業で 多く 使われる - Vercel / Netlify — フロントエンドの
デプロイに 特化。GitHubと 連携するだけで 自動デプロイ
未経験エンジニアがCI/CDで知っておくべきこと
最低限の知識
- CIが
何をしているか 理解する (テストの 自動実行、 リンターの チェック) - CIが
失敗した とき、 ログを 読んで 原因を 特定できる - デプロイの
基本的な 流れを 理解する
ポートフォリオでCI/CDを取り入れる
ポートフォリオに
- GitHub Actionsで
テストの 自動実行を 設定する - Vercelと
連携して、mainブランチへの マージで 自動デプロイする - テストカバレッジの
バッジを READMEに 表示する
これだけで、「この
CI/CDは「チームの安全装置」
CI/CDは、
ゆめさくエンジニアの
デプロイまで
実務で
ブランチ戦略から
Webエンジニアの
XSS・CSRF・SQLインジェクションを
現場で
スクールでは
ゆめさくエンジニアの
18ヶ月で




