PL Programming Lab
CI/CD（Continuous Integration / Continuous Delivery & Deployment）

CI/CD

継続的インテグレーション／継続的デリバリー（デプロイ）。ビジネスとITをつなぐ“安全に速く出す”仕組み。

狙い
安全に速く出す
手作業を減らし、品質を上げる
対象
ビルド / テスト / 配布
繰り返し作業を自動化
成果
早期バグ検知
小さく早く回して手戻り減
パイプライン例を見る 導入の進め方へ

CI/CDとは

CI/CD は、コード変更を継続的に統合（CI）し、いつでも出せる状態（CD）を保つための 開発プロセス（＋自動化の仕組み）です。一般に CI/CD はソフトウェア開発ライフサイクルを速く・安全にする目的で使われます。

用語の整理
  • CI：ビルドとテスト（＋静的解析など）を自動で回し、統合を壊さない
  • CD（Delivery）：本番リリース“可能”な状態まで自動で整える（最後の承認は人が押すことが多い）
  • CD（Deployment）：テストに通ったら自動で本番へ反映まで行う

Continuous Delivery / Deployment の説明は、AWS の定義でも整理されます。

CIの中心
壊れてないかを自動で証明
CDの中心
安全に出すための段取りを自動化
本番の恐怖を減らす
小さく出して戻せるようにする

ビジネス上の価値

なぜ“ITの話”が“ビジネスの話”になる？

リリースが遅いと、機会損失（売上・顧客満足）に直結します。 一方、速さだけ追うと障害・品質問題で信用を落とします。 CI/CD は、この速さと安全のトレードオフを、仕組みで崩す発想です。

  • 手順が自動化され、人の“うっかり”が減る
  • 変更が小さくなり、レビューと検証が楽になる
  • 問題が早期に見つかり、修正コストが下がる
効く場面
変更が多い
Web / アプリ / API
効きにくい場面
年数回しか出さない
テスト自動化コストが上回る
最重要
“戻せる”設計
ロールバック/Feature Flag

CI（継続的インテグレーション）

Push / PR
Build
Test
Report

CI は「コミットしたら自動でテストが回る」だけでなく、 “統合しても壊れない状態”を保ち続けるための習慣です。

CIでよく入るチェック例
# 例：CIの典型チェック
- 依存関係インストール（npm/pip/bundle 等）
- ビルド（コンパイル/バンドル）
- Lint（ESLint/ruff 等）
- 型チェック（TypeScript/mypy 等）
- 単体テスト（Jest/pytest 等）
- カバレッジ計測
- セキュリティスキャン（依存関係/コンテナ）
CIが止まる“あるある”
  • テストが遅すぎる → 開発が待たされる
  • 落ちる理由が曖昧 → “直し方がわからない”
  • 一部の人だけ直す → “CI番長”が誕生

対策：テストの層分け（速いテストを先に）＋ログ整備＋所有権ルール。

CD（Delivery / Deployment）

CD は「出すところまでの自動化」です。 特に、Delivery（いつでも出せる）とDeployment（自動で出る）が混ざりやすいので、運用方針で決めます。 :contentReference[oaicite:1]{index=1}

Continuous Delivery

  • 本番反映は“人の承認ボタン”
  • 監査・コンプラ・慎重な業務に合う
  • 「いつでも出せる」を守る

Continuous Deployment

  • テスト合格で本番へ自動反映
  • スピード勝負のプロダクトに合う
  • ロールバック設計が必須
Feature Flag
“デプロイ”と“公開”を分離できる
Blue/Green
切り替えで安全に移行
Canary
少数ユーザーから段階展開

DevOpsとCI/CDの違い・関係

DevOps は「開発と運用が協力して、継続的に価値提供する文化・体制」寄りの概念で、 CI/CD はそれを実現するための具体的な仕組み（自動化パイプライン）として語られることが多いです。 :contentReference[oaicite:2]{index=2}

ざっくり一言

DevOps = “どう働くか” ／ CI/CD = “どう回すか”

パイプライン構成例

“最低限の型”はこの順番です（プロダクトにより増減）。

Commit→ Build→ Test→ Package→ Deploy(Staging)→ Approve→ Deploy(Prod)
コツ：失敗しやすい＆速い検査を前半に寄せる（Lint/Unit → Integration → E2E）。
例：環境別に段階リリース（疑似コード）
stages:
  - validate
  - test
  - build
  - deploy_stg
  - deploy_prod

validate:  lint / typecheck
test:      unit + integration
build:     container build + scan
deploy_stg: auto deploy + smoke test
deploy_prod: manual approve then deploy + canary

代表的ツール

“ツール名を覚える”より、自分のチームがどこまで自動化したいかで選ぶのが勝ちです。 例として、GitHub Actions / GitLab CI/CD / Jenkins を挙げます。 :contentReference[oaicite:3]{index=3}

GitHub Actions
GitHub内蔵
  • リポジトリイベント（PR/Push等）でワークフロー実行
  • MarketplaceでActionが豊富
  • セルフホストRunnerも可能
Docs: GitHub公式
GitLab CI/CD
.gitlab-ci.yml
  • パイプライン中心、YAMLで定義
  • Runnerでジョブを実行
  • MR連携や環境管理が強い
Docs: GitLab公式
Jenkins
OSS / 拡張性
  • プラグインが膨大で自由度高い
  • オンプレ/自前運用の定番
  • JenkinsfileでPipeline定義
Docs: Jenkins公式
観点 GitHub Actions GitLab CI/CD Jenkins
導入 GitHubなら即 GitLabなら即 サーバ構築が必要
運用コスト 低〜中 低〜中 中〜高
自由度 中 中 高
向く場面 GitHub中心の開発 GitLab中心の開発 複雑要件/社内基盤

導入の進め方（現場）

  1. まずCIだけ
    最初から“本番自動デプロイ”を狙うと壊れやすい。まずは build + test を固める。
  2. 速いテストを優先
    Lint/Unit を先に通す。遅いE2Eは後ろへ。失敗理由はログで即わかるように。
  3. CDは「ステージング → 本番」
    ステージング自動、プロダクションは手動承認（Delivery）から入るのが安全。
  4. ロールバック設計
    Blue/Green、Canary、Feature Flag。戻せない自動化は事故る。
“最初の勝ち筋”

①テストが速い → ②落ちた理由が一瞬でわかる → ③直す担当が決まってる これが揃うとCI/CDは“快適装置”になります。

運用チェックリスト

※チェック状態はブラウザに保存（localStorage）されます。

FAQ

CI/CDって、結局“ツール”のこと？
どちらかというとやり方（プロセス）の話で、ツールは実現手段です。 とはいえ現場では「CI/CD = パイプライン」としてツール名が会話に出やすいです。 :contentReference[oaicite:4]{index=4}
DevOpsと同じ意味？
DevOps は文化・体制寄り、CI/CD は自動化の仕組み寄り、という整理がわかりやすいです。 :contentReference[oaicite:5]{index=5}
CDはDeliveryとDeploymentどっち？
現場の文脈で両方あります。混乱を避けるには「Delivery（手動承認あり）」「Deployment（自動反映）」と明示して話すのが安全です。 :contentReference[oaicite:6]{index=6}