CI/CDベストプラクティス2025：チームのためのパイプライン設計、自動化、セキュリティまで

従来のアプローチ:
Code → Build → Test → Security → Deploy → Monitor
                              ↑ ここで問題発見

シフトレフト:
Code + Test + Security → Build → Deploy → Monitor
↑ ここで問題発見 (コスト10倍削減)

# .github/workflows/ci.yml
name: CI Pipeline

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

concurrency:
  group: ci-${{ '{{' }} github.ref {{ '}}' }}
  cancel-in-progress: true

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --shard=${{ '{{' }} matrix.shard {{ '}}' }}/4

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: myapp:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

// Jenkinsfile (Declarative Pipeline)
pipeline {
    agent any

    environment {
        DOCKER_REGISTRY = 'registry.example.com'
        IMAGE_NAME = 'myapp'
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Lint & Test') {
            parallel {
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Unit Test') {
                    steps {
                        sh 'npm test -- --coverage'
                    }
                    post {
                        always {
                            junit 'reports/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Build & Push') {
            steps {
                script {
                    def image = docker.build("${DOCKER_REGISTRY}/${IMAGE_NAME}:${BUILD_NUMBER}")
                    docker.withRegistry("https://${DOCKER_REGISTRY}", 'registry-credentials') {
                        image.push()
                        image.push('latest')
                    }
                }
            }
        }
    }

    post {
        failure {
            slackSend(
                channel: '#ci-alerts',
                color: 'danger',
                message: "Build FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
            )
        }
    }
}

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  DOCKER_HOST: tcp://docker:2376

lint:
  stage: lint
  image: node:20-alpine
  cache:
    key: npm-cache
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  image: node:20-alpine
  parallel: 4
  script:
    - npm ci
    - npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
  coverage: '/Statements\s*:\s*(\d+\.?\d*)%/'
  artifacts:
    reports:
      junit: reports/junit.xml

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t myapp:latest .
    - docker push myapp:latest
  only:
    - main

目標時間:
├── リント + フォーマットチェック: 30秒以内
├── ユニットテスト: 2分以内
├── 統合テスト: 5分以内
├── ビルド: 3分以内
└── 全パイプライン: 10分以内

現実 (最適化前): 30分以上
現実 (最適化後): 8〜10分

# 並列パイプライン例
jobs:
  # フェーズ1: リント/セキュリティは独立して並列実行
  lint:
    runs-on: ubuntu-latest
    # ...
  security-scan:
    runs-on: ubuntu-latest
    # ...

  # フェーズ2: テストはシャードで並列分割
  test:
    needs: [lint]
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    # ...

  # フェーズ3: テスト通過後にビルド
  build:
    needs: [test, security-scan]
    # ...

# npmキャッシュ（GitHub Actions）
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ '{{' }} hashFiles('**/package-lock.json') {{ '}}' }}
    restore-keys: |
      npm-

# Dockerレイヤーキャッシュ
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

# Gradleキャッシュ
- uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: gradle-${{ '{{' }} hashFiles('**/*.gradle*') {{ '}}' }}

# 悪い例: タイムスタンプベースのタグ（再実行時に異なる結果）
# IMAGE_TAG: my-app:build-20250323-142000

# 良い例: コミットSHAベースのタグ（常に同一）
# IMAGE_TAG: my-app:abc1234

# 良い例: セマンティックバージョン（決定的）
# IMAGE_TAG: my-app:v1.2.3

          /   E2E    \          遅いが高い信頼性
         /  (5〜10%)  \
        / Integration  \       中速度、中信頼性
       /   (15〜25%)    \
      /   Unit Tests     \    高速で大量
     /     (65〜80%)      \
    /______________________\

# Jestテストシャーディング
test:
  strategy:
    matrix:
      shard: [1, 2, 3, 4]
  steps:
    - run: npx jest --shard=${{ '{{' }} matrix.shard {{ '}}' }}/4

# Cypress並列実行
e2e:
  strategy:
    matrix:
      container: [1, 2, 3]
  steps:
    - uses: cypress-io/github-action@v6
      with:
        record: true
        parallel: true
        group: 'e2e-tests'

// フレイキーテスト検出・隔離戦略
// jest.config.js
module.exports = {
  // 失敗時に自動リトライ
  retryTimes: 2,

  // フレイキーテストレポーター
  reporters: [
    'default',
    ['jest-flaky-reporter', {
      outputFile: 'flaky-tests.json',
      threshold: 3  // 3回以上フレイキーなら報告
    }]
  ]
};

# CIでフレイキーテストを隔離
test-stable:
  runs-on: ubuntu-latest
  steps:
    - run: npx jest --testPathIgnorePatterns="flaky"

test-flaky:
  runs-on: ubuntu-latest
  continue-on-error: true  # 失敗してもパイプライン継続
  steps:
    - run: npx jest --testPathPattern="flaky" --retries=3

# カバレッジ閾値設定
test:
  steps:
    - run: npx jest --coverage
    - name: Check coverage threshold
      run: |
        COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.statements.pct')
        if (( $(echo "$COVERAGE < 80" | bc -l) )); then
          echo "Coverage $COVERAGE% is below 80% threshold"
          exit 1
        fi

# Stage 1: 依存関係インストール
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production

# Stage 2: ビルド
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Stage 3: プロダクションイメージ
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# セキュリティ: non-rootユーザー
RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

COPY --from=builder --chown=nextjs:nodejs /app/.next ./.next
COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

USER nextjs
EXPOSE 3000
CMD ["npm", "start"]

# 悪い例: ソース変更時にnpm ci再実行
COPY . .
RUN npm ci
RUN npm run build

# 良い例: 依存関係ファイルのみ先にコピー
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# GitHub ActionsでBuildKit使用
- uses: docker/setup-buildx-action@v3

- uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: myapp:latest
    cache-from: type=gha
    cache-to: type=gha,mode=max
    platforms: linux/amd64,linux/arm64

# KubernetesでKanikoによるイメージビルド
apiVersion: v1
kind: Pod
metadata:
  name: kaniko-build
spec:
  containers:
    - name: kaniko
      image: gcr.io/kaniko-project/executor:latest
      args:
        - "--dockerfile=Dockerfile"
        - "--context=git://github.com/myorg/myapp"
        - "--destination=registry.example.com/myapp:latest"
        - "--cache=true"
        - "--cache-repo=registry.example.com/myapp/cache"

イメージサイズ比較:
├── node:20          → 1.1GB
├── node:20-slim     → 220MB
├── node:20-alpine   → 140MB
├── distroless/nodejs → 120MB
└── マルチステージ最適化 → 80〜100MB

GitOpsワークフロー:
1. 開発者がGitに変更をPush
2. CIがイメージをビルド・テスト
3. CIがデプロイマニフェストのイメージタグを更新
4. ArgoCDがGitとクラスター状態を比較
5. 差異があれば自動同期（または手動承認）
6. クラスターがGit状態と一致

┌────────┐    Push     ┌────────┐   Detect   ┌────────┐
│  Dev   │ ──────────> │  Git   │ <────────> │ ArgoCD │
└────────┘             └────────┘            └───┬────┘
                                                 │ Sync
                                            ┌────▼────┐
                                            │  K8s    │
                                            │ Cluster │
                                            └─────────┘

# apps/root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/gitops-config
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

# apps/api-service.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/gitops-config
    path: services/api
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-service
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: api-canary
      stableService: api-stable
      trafficRouting:
        istio:
          virtualService:
            name: api-vsvc
      steps:
        - setWeight: 10
        - pause:
            duration: 5m
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 30
        - pause:
            duration: 5m
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 60
        - pause:
            duration: 5m
        - setWeight: 100

# AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 60s
      successCondition: result[0] >= 0.95
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{status=~"2.*",app="api-service",version="canary"}[5m]))
            /
            sum(rate(http_requests_total{app="api-service",version="canary"}[5m]))

CI/CDセキュリティレイヤー:
┌─────────────────────────────────────────────┐
│ Layer 1: Pre-commit                         │
│  - Secret scanning (gitleaks, detect-secrets)│
│  - Lint (security rules)                    │
├─────────────────────────────────────────────┤
│ Layer 2: PR / Build                         │
│  - SAST (Semgrep, CodeQL, SonarQube)        │
│  - SCA (Dependabot, Snyk, Trivy)            │
│  - License compliance                       │
├─────────────────────────────────────────────┤
│ Layer 3: Container Build                    │
│  - Image scanning (Trivy, Grype)            │
│  - Base image policy (distroless, alpine)   │
│  - SBOM generation (Syft)                   │
├─────────────────────────────────────────────┤
│ Layer 4: Deploy                             │
│  - Policy enforcement (OPA/Kyverno)         │
│  - Signing (cosign, Sigstore)               │
│  - Runtime security (Falco)                 │
└─────────────────────────────────────────────┘

# GitHub Actionsでシークレット使用
deploy:
  steps:
    - name: Deploy
      env:
        AWS_ACCESS_KEY_ID: ${{ '{{' }} secrets.AWS_ACCESS_KEY_ID {{ '}}' }}
        AWS_SECRET_ACCESS_KEY: ${{ '{{' }} secrets.AWS_SECRET_ACCESS_KEY {{ '}}' }}
      run: |
        aws ecs update-service --cluster prod --service api

# OIDC認証（シークレットレス方式 - 推奨）
permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-actions
      aws-region: ap-northeast-2

# SyftでSBOM生成
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: myapp:latest
    format: spdx-json
    output-file: sbom.spdx.json

# cosignでイメージ署名
- name: Sign image
  run: |
    cosign sign --key env://COSIGN_PRIVATE_KEY myapp:latest

# cosignで署名検証
- name: Verify signature
  run: |
    cosign verify --key cosign.pub myapp:latest

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# CIでgitleaks実行
security:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0
    - uses: gitleaks/gitleaks-action@v2
      env:
        GITHUB_TOKEN: ${{ '{{' }} secrets.GITHUB_TOKEN {{ '}}' }}

# Kubernetes Blue-Greenデプロイ
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
    version: green  # blueからgreenに切替
  ports:
    - port: 80
      targetPort: 8080

Blue-Green切替プロセス:
1. Blue(v1)運用中 → Green(v2)デプロイ
2. Greenヘルスチェック・スモークテスト
3. Service selectorをGreenに切替
4. 問題時はBlueに即時ロールバック
5. 安定化後にBlueリソースを整理

[Users] → [LB] → [Blue v1] Active
                  [Green v2] ← 準備中

[Users] → [LB] → [Blue v1] ← 待機
                  [Green v2] Active

# Istio VirtualServiceでカナリアデプロイ
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-service
spec:
  hosts:
    - api-service
  http:
    - route:
        - destination:
            host: api-service
            subset: stable
          weight: 90
        - destination:
            host: api-service
            subset: canary
          weight: 10

// LaunchDarklyまたは自社Feature Flagシステム
import { featureFlags } from './feature-flags';

async function handleRequest(req: Request) {
  const userId = req.user.id;

  if (await featureFlags.isEnabled('new-checkout-flow', userId)) {
    return newCheckoutFlow(req);
  }

  return legacyCheckoutFlow(req);
}

Feature Flagベースのデプロイ:
1. 新機能をフラグで囲んでコードをデプロイ
2. 内部ユーザーのみ有効化
3. 段階的に割合を拡大（1% → 5% → 25% → 100%）
4. 問題時はフラグを無効にするだけで即時非活性化
5. デプロイとリリースを分離

# Argo Rollouts自動ロールバック
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - analysis:
            templates:
              - templateName: error-rate-check
      # 分析失敗時に自動ロールバック
      abortScaleDownDelaySeconds: 30

# Kubernetes Deployment自動ロールバック
apiVersion: apps/v1
kind: Deployment
spec:
  progressDeadlineSeconds: 300  # 5分以内に完了しなければ失敗
  minReadySeconds: 30
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0

// デプロイサーキットブレイカー
class DeploymentCircuitBreaker {
  private errorThreshold = 0.05; // 5%エラー率
  private windowSize = 300;       // 5分ウィンドウ

  async shouldRollback(metrics: DeploymentMetrics): Promise<boolean> {
    const errorRate = metrics.errors / metrics.totalRequests;
    const p99Latency = metrics.p99LatencyMs;

    return (
      errorRate > this.errorThreshold ||
      p99Latency > 3000 // 3秒超過
    );
  }

  async executeRollback(deployment: string) {
    console.log(`Rolling back ${deployment}`);
    await exec(`kubectl rollout undo deployment/${deployment}`);

    await notify({
      channel: '#deployments',
      message: `Auto-rollback triggered for ${deployment}`,
      severity: 'critical'
    });
  }
}

安全なDBマイグレーション戦略:
1. Expand-Contractパターン
   Phase 1 (Expand): 新カラム追加、両方に書き込み
   Phase 2 (Migrate): 既存データの移行
   Phase 3 (Contract): 旧カラム削除

2. ロールバック可能なマイグレーションのみ適用
   - カラム追加（ロールバック可能）
   - インデックス追加（ロールバック可能）
   - カラム削除（ロールバック不可 → Expand-Contract使用）
   - 型変更（ロールバック不可 → 新カラム追加後に切替）

-- 安全なマイグレーション例
-- Step 1: 新カラム追加（ロールバック可能）
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT FALSE;

-- Step 2: データマイグレーション（バックグラウンド）
UPDATE users SET email_verified = TRUE
WHERE verified_at IS NOT NULL;

-- Step 3: アプリコードで新カラム使用に切替
-- Step 4: 旧カラム削除（別マイグレーション）
-- ALTER TABLE users DROP COLUMN verified_at;

パイプラインヘルスダッシュボード:
┌─────────────────────────────────────────┐
│  Build Time Trend                       │
│  ██████████████ 8m (avg)                │
│  Target: < 10m                          │
├─────────────────────────────────────────┤
│  Success Rate                           │
│  ████████████████████ 94%               │
│  Target: > 95%                          │
├─────────────────────────────────────────┤
│  Flaky Test Rate                        │
│  ██ 3%                                  │
│  Target: < 2%                           │
├─────────────────────────────────────────┤
│  Mean Time to Recovery (MTTR)           │
│  ████ 25min                             │
│  Target: < 30min                        │
└─────────────────────────────────────────┘

# ビルドメトリクスをDatadogに報告
- name: Report build metrics
  if: always()
  run: |
    END_TIME=$(date +%s)
    DURATION=$((END_TIME - START_TIME))
    curl -X POST "https://api.datadoghq.com/api/v1/series" \
      -H "DD-API-KEY: $DD_API_KEY" \
      -d "{
        \"series\": [{
          \"metric\": \"ci.build.duration\",
          \"points\": [[$END_TIME, $DURATION]],
          \"tags\": [
            \"repo:myapp\",
            \"branch:$GITHUB_REF_NAME\",
            \"status:$JOB_STATUS\"
          ]
        }]
      }"

# ビルド失敗自動分類スクリプト
import re
from enum import Enum

class FailureCategory(Enum):
    FLAKY_TEST = "flaky_test"
    DEPENDENCY = "dependency"
    COMPILATION = "compilation"
    INFRASTRUCTURE = "infrastructure"
    TIMEOUT = "timeout"
    UNKNOWN = "unknown"

def categorize_failure(log: str) -> FailureCategory:
    patterns = {
        FailureCategory.FLAKY_TEST: [
            r"retry.*failed",
            r"intermittent",
            r"flaky"
        ],
        FailureCategory.DEPENDENCY: [
            r"npm ERR!.*404",
            r"Could not resolve dependencies",
            r"ECONNRESET"
        ],
        FailureCategory.COMPILATION: [
            r"error TS\d+",
            r"SyntaxError",
            r"TypeError"
        ],
        FailureCategory.INFRASTRUCTURE: [
            r"runner.*offline",
            r"disk space",
            r"out of memory"
        ],
        FailureCategory.TIMEOUT: [
            r"timed out",
            r"deadline exceeded"
        ]
    }

    for category, regexes in patterns.items():
        for pattern in regexes:
            if re.search(pattern, log, re.IGNORECASE):
                return category

    return FailureCategory.UNKNOWN