CI/CD

この用語をシェア

概要・定義

CI/CD（Continuous Integration/Continuous Delivery）は、ソフトウェア開発において、コードの統合・テスト・デプロイを自動化する開発手法です。CI（継続的インテグレーション）は、開発者が頻繁にコードを共有リポジトリに統合し、自動的にビルドとテストを実行する手法です。CD（継続的デリバリー）は、テスト済みのコードを自動的に本番環境にデプロイする手法です。

CI/CDは、DevOps文化の中核を担う重要な概念であり、2000年代初頭のExtreme Programming（XP）の実践から発展しました。現代のソフトウェア開発では、品質向上、リリース頻度の向上、リスク軽減を実現するために不可欠な手法となっています。

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

概要

開発者が頻繁に（通常は1日に数回）コードをメインブランチに統合し、統合のたびに自動的にビルドとテストを実行する開発手法です。

主要な特徴

• 頻繁な統合: 小さな変更を頻繁に統合
• 自動ビルド: コードのコミット時に自動的にビルド実行
• 自動テスト: 単体テスト、統合テストの自動実行
• 即座のフィードバック: 問題を早期に発見・修正

利点

• 統合の問題を早期に発見
• コード品質の向上
• 開発効率の向上
• リリース可能な状態の維持

CD（継続的デリバリー/継続的デプロイメント）

継続的デリバリー（Continuous Delivery）

CIで検証されたコードを、手動承認を経て本番環境にデプロイできる状態に自動的に準備する手法です。

継続的デプロイメント（Continuous Deployment）

テストをパスしたコードを、人間の介入なしに自動的に本番環境にデプロイする手法です。

主要な特徴

• 自動デプロイ: 承認プロセスを経た自動デプロイ
• 環境の一貫性: 開発から本番まで一貫した環境
• ロールバック機能: 問題発生時の迅速な復旧
• リリース戦略: Blue-Green、Canary等の安全なリリース

CI/CDパイプラインの構成

典型的なパイプライン

1. ソースコード管理: Git等でのコード管理
2. ビルド: コードのコンパイル・パッケージ化
3. テスト: 単体テスト、統合テスト、E2Eテスト
4. 静的解析: コード品質、セキュリティチェック
5. アーティファクト作成: デプロイ用成果物の作成
6. ステージング環境デプロイ: 本番環境への前段階
7. 承認プロセス: 手動または自動承認
8. 本番環境デプロイ: 実際のリリース
9. 監視・検証: デプロイ後の動作確認

主要なCI/CDツール

クラウドベースCI/CD

• GitHub Actions: GitHub統合型CI/CD
• GitLab CI/CD: GitLab統合型CI/CD
• Azure DevOps: Microsoft提供のDevOpsプラットフォーム
• AWS CodePipeline: AWS提供のCI/CDサービス
• Google Cloud Build: Google Cloud提供のCI/CDサービス

オンプレミス・セルフホスト

• Jenkins: オープンソースの定番CI/CDツール
• CircleCI: クラウド・オンプレミス両対応
• TeamCity: JetBrains製のCI/CDツール
• Bamboo: Atlassian製のCI/CDツール

実装例

GitHub Actions ワークフロー

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests
      run: npm test
    
    - name: Run linting
      run: npm run lint
    
    - name: Run security audit
      run: npm audit
  
  build:
    needs: test
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build application
      run: npm run build
    
    - name: Build Docker image
      run: docker build -t myapp:${{ github.sha }} .
    
    - name: Push to registry
      run: |
        echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
        docker push myapp:${{ github.sha }}
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    steps:
    - name: Deploy to production
      run: |
        # デプロイスクリプトの実行
        kubectl set image deployment/myapp myapp=myapp:${{ github.sha }}

メリット・デメリット

メリット

• バグや統合の問題を早期に発見でき、修正コストを抑えられる
• リリース作業が自動化・標準化され、人為的ミスが減る
• リリース頻度を高められ、ユーザーへの価値提供サイクルが短縮される
• テストやビルドの実行履歴が残り、品質のトレーサビリティが向上する

デメリット・注意点

• 初期構築コスト: パイプラインの設計・テスト自動化の整備には一定の工数が必要で、テストが不十分なプロジェクトほど導入効果が出にくい
• 誤った自動デプロイのリスク: テストカバレッジが低い状態で継続的デプロイを行うと、不具合が本番環境に即座に反映されてしまう
• 運用・保守負荷: パイプライン自体も設定ファイルとして管理・保守する対象になり、複雑化すると理解できるメンバーが限られてしまうことがある
• 実行時間の増大: プロジェクトが大きくなるとビルド・テストの実行時間が伸び、開発体験を損なう場合がある（キャッシュや並列実行での対策が必要）

主要CI/CDツールの比較

実務での活用シーン・導入時の注意点

代表的な活用シーン

• Webアプリ・APIの継続的リリース: mainブランチへのマージをトリガーに、テスト・ビルド・本番デプロイを自動実行
• モバイルアプリのビルド自動化: iOS/Androidのビルド・署名・ストア申請プロセスの自動化
• インフラのCI/CD（GitOps）: Terraformコードの変更をトリガーに、plan/applyを自動実行
• セキュリティチェックの自動化: 依存パッケージの脆弱性スキャンやSAST（静的解析）をパイプラインに組み込む

導入時に気をつけたいポイント

• まずはCI（自動テスト・ビルド）から着手し、信頼性が確認できてから段階的にCD（自動デプロイ）へ拡張する
• 本番デプロイには承認ステップやカナリアリリースなど、リスクを抑える仕組みを組み込む
• シークレット（APIキー等）はパイプライン内にハードコードせず、GitHub SecretsなどのSecret管理機能を利用する

外部リンク

• GitHub Actions公式ドキュメント
• GitLab CI/CD公式ドキュメント
• Jenkins公式ドキュメント

関連用語

• Docker（コンテナ技術）
• Kubernetes（コンテナオーケストレーション）
• Terraform（インフラコード化）
• GitHub Actions
• Jenkins（CI/CDツール）