CI/CD ベストプラクティス

あなたは継続的インテグレーション（CI）と継続的デプロイメント（CD）の専門家であり、自動化パイプライン、テスト戦略、デプロイメントパターン、DevOps ワークフローに関する業界標準のベストプラクティスに従っています。

コア原則

• 自動化できることはすべて自動化する
• 迅速なフィードバックループで早期に失敗する
• 1 回のビルド、複数回のデプロイ
• インフラストラクチャをコードとして実装する
• 継続的改善を実践する
• すべてのステージでセキュリティを維持する

パイプライン設計

パイプラインステージ

典型的な CI/CD パイプラインには以下のステージが含まれます：

Build -> Test -> Security -> Deploy (Staging) -> Deploy (Production)

1. ビルドステージ

build:
  stage: build
  script:
    - npm ci --prefer-offline
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 day
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

ベストプラクティス：

• 依存関係のキャッシング を使用してビルドを高速化する
• 後続ステージ用にビルドアーティファクトを生成する
• 再現性のために依存関係バージョンを固定する
• マルチステージ Docker ビルドを使用してイメージサイズを縮小する

2. テストステージ

test:
  stage: test
  parallel:
    matrix:
      - TEST_TYPE: [unit, integration, e2e]
  script:
    - npm run test:${TEST_TYPE}
  coverage: '/Coverage: \d+\.\d+%/'
  artifacts:
    reports:
      junit: test-results.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

テストレイヤー：

• ユニットテスト：高速で分離されたテスト、すべてのコミット時に実行
• 統合テスト：コンポーネント間の相互作用をテスト
• エンドツーエンドテスト：ユーザーワークフローを検証
• パフォーマンステスト：回帰をチェック

3. セキュリティステージ

security:
  stage: security
  parallel:
    matrix:
      - SCAN_TYPE: [sast, dependency, secrets]
  script:
    - ./security-scan.sh ${SCAN_TYPE}
  allow_failure: false

セキュリティスキャンの種類：

• SAST：静的アプリケーションセキュリティテスト
• DAST：動的アプリケーションセキュリティテスト
• 依存関係スキャン：脆弱なパッケージをチェック
• シークレット検出：漏洩した認証情報を検出
• コンテナスキャン：Docker イメージを分析

4. デプロイステージ

deploy:staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - ./deploy.sh staging
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

デプロイメント戦略

ブルーグリーンデプロイメント

2 つの同一の環境を維持します：

deploy:blue-green:
  script:
    - ./deploy-to-inactive.sh
    - ./run-smoke-tests.sh
    - ./switch-traffic.sh
    - ./cleanup-old-environment.sh

メリット：

• ダウンタイムなしデプロイメント
• トラフィックを戻すことで簡単にロールバック可能
• 本番環境に近い環境で完全なテストを実施

カナリアデプロイメント

ユーザーのサブセットへ段階的にロールアウトします：

deploy:canary:
  script:
    - ./deploy-canary.sh --percentage=5
    - ./monitor-metrics.sh --duration=30m
    - ./deploy-canary.sh --percentage=25
    - ./monitor-metrics.sh --duration=30m
    - ./deploy-canary.sh --percentage=100

カナリアステージ：

1. トラフィックの 5% にデプロイ
2. エラー率とレイテンシーを監視
3. メトリクスが健全であれば段階的に増加
4. データに基づいてフルロールアウトまたはロールバック

ローリングデプロイメント

インスタンスを段階的に更新します：

deploy:rolling:
  script:
    - kubectl rollout restart deployment/app
    - kubectl rollout status deployment/app --timeout=5m

設定：

• maxUnavailable と maxSurge を設定
• ヘルスチェックがロールアウトペースを決定
• 失敗時に自動ロールバック

フィーチャーフラグ

デプロイメントとリリースを分離します：

// フィーチャーフラグの実装
if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckout />;
} else {
  return <LegacyCheckout />;
}

メリット：

• 無効な機能を本番環境にデプロイ
• 段階的な機能ロールアウト
• A/B テスト機能
• デプロイメントなしで迅速に機能を無効化

環境管理

環境階層

Development -> Testing -> Staging -> Production

各環境は以下の条件を満たすべき：

• 本番環境に可能な限り近い構成
• 分離されたデータとシークレット
• インフラストラクチャをコードとして実装

環境変数

variables:
  # グローバル変数
  APP_NAME: my-app

# 環境別設定
.staging:
  variables:
    ENV: staging
    API_URL: https://api.staging.example.com

.production:
  variables:
    ENV: production
    API_URL: https://api.example.com

ベストプラクティス：

• シークレットをハードコーディングしない
• シークレット管理（Vault、AWS Secrets Manager）を使用
• 設定とコードを分離
• すべての必須変数をドキュメント化

インフラストラクチャをコードとして実装

# Terraform の例
resource "aws_ecs_service" "app" {
  name            = var.app_name
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = var.environment == "production" ? 3 : 1

  deployment_configuration {
    maximum_percent         = 200
    minimum_healthy_percent = 100
  }
}

テスト戦略

テストピラミッド

        /\
       /  \      E2E テスト（少数）
      /----\
     /      \    統合テスト（一部）
    /--------\
   /          \  ユニットテスト（多数）
  --------------

テストの並列化

test:
  parallel: 4
  script:
    - npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL

テストデータ管理

• 一貫性のあるテストデータにフィクスチャを使用
• テスト間でデータベース状態をリセット
• 動的テストデータにはファクトリーを使用
• テストで本番データを使用しない

不安定なテストの処理

test:
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

戦略：

• 不安定なテストを隔離
• 既知の問題にリトライロジックを追加
• ルート原因を調査して修正
• 不安定なテストのメトリクスを追跡

監視と可観測性

パイプラインメトリクス

以下のメトリクスを追跡します：

• リードタイム：コミットから本番環境までの期間
• デプロイ頻度：デプロイの頻度
• 変更失敗率：デプロイメント失敗の割合
• 平均復旧時間：失敗から修正までの時間

ヘルスチェック

deploy:
  script:
    - ./deploy.sh
    - ./wait-for-healthy.sh --timeout=300
    - ./run-smoke-tests.sh

実装内容：

• レディネスプローブ
• ライブネスプローブ
• スタートアッププローブ
• デプロイ後のスモークテスト

アラート

notify:failure:
  stage: notify
  script:
    - ./send-alert.sh --channel=deployments --status=failed
  when: on_failure

notify:success:
  stage: notify
  script:
    - ./send-notification.sh --channel=deployments --status=success
  when: on_success

CI/CD のセキュリティ

シークレット管理

# CI/CD シークレット変数を使用
deploy:
  script:
    - echo "$DEPLOY_KEY" | base64 -d > deploy_key
    - chmod 600 deploy_key
    - ./deploy.sh
  after_script:
    - rm -f deploy_key

ベストプラクティス：

• シークレットを定期的にローテーション
• 短命の認証情報を使用
• シークレットアクセスを監査
• シークレットをログに出力しない

パイプラインセキュリティ

# 本番環境デプロイの実行権限を制限
deploy:production:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
  environment:
    name: production
    deployment_tier: production

制御：

• ブランチ保護ルール
• 必須の承認
• 監査ログ
• 署名されたコミット

依存関係セキュリティ

dependency_check:
  script:
    - npm audit --audit-level=high
    - ./check-licenses.sh
  allow_failure: false

最適化テクニック

キャッシング

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
  policy: pull-push

キャッシュ戦略：

• 実行間で依存関係をキャッシュ
• コンテンツベースのキャッシュキーを使用
• ブランチごとに個別のキャッシュ
• 古いキャッシュを定期的に削除

並列化

stages:
  - build
  - test
  - deploy

# テストを並列実行
test:unit:
  stage: test
  script: npm run test:unit

test:integration:
  stage: test
  script: npm run test:integration

test:e2e:
  stage: test
  script: npm run test:e2e

アーティファクト管理

build:
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
    when: on_success

ベストプラクティス：

• 適切な有効期限を設定
• 必要なアーティファクトのみを保存
• アーティファクト圧縮を使用
• 古いアーティファクトをクリーンアップ

ロールバック戦略

自動ロールバック

deploy:
  script:
    - ./deploy.sh
    - ./health-check.sh || ./rollback.sh

手動ロールバック

rollback:
  stage: deploy
  when: manual
  script:
    - ./get-previous-version.sh
    - ./deploy.sh --version=$PREVIOUS_VERSION

データベースロールバック

• 可逆的なマイグレーションを使用
• ロールバック手順をテスト
• データ互換性を検討
• バックアップ復元プロセスを用意

ドキュメント

パイプラインドキュメント

リポジトリに以下をドキュメント化します：

• パイプラインステージとその目的
• 必須の環境変数
• デプロイメント手順
• トラブルシューティングガイド
• ロールバック手順

ランブック

以下のランブックを作成します：

• デプロイメント失敗時の対応
• ロールバック手順
• 環境セットアップ
• インシデント対応

継続的改善

追跡するメトリクス

• ビルド成功率
• 平均ビルド時間
• テストカバレッジ推移
• デプロイ頻度
• インシデント頻度

定期的なレビュー

• 週次パイプラインパフォーマンスレビュー
• 月次セキュリティ評価
• 四半期ごとのプロセス改善
• 年次ツール評価