ci-cd-best-practices

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

自動化されたパイプライン、テスト戦略、デプロイパターン、DevOps ワークフローに関する業界のベストプラクティスに従う、継続的インテグレーションと継続的デプロイメントの専門家です。

基本原則

• 自動化できるものはすべて自動化します
• 迅速なフィードバックループで早期に失敗を検知します
• 一度ビルドし、何度でもデプロイします
• Infrastructure as Code を実践します
• 継続的な改善に取り組みます
• すべての段階でセキュリティを維持します

パイプライン設計

パイプラインの段階

一般的な 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 を設定します
• ヘルスチェックで展開のペースを判断します
• 失敗時は自動でロールバックします

フィーチャーフラグ

デプロイとリリースを切り離します。

// Feature flag implementation
if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckout />;
} else {
  return <LegacyCheckout />;
}

メリット：

• 無効化した機能を本番環境にデプロイできます
• 機能を段階的に展開できます
• A/B テストを実施できます
• デプロイせずに機能をすばやく無効化できます

環境管理

環境の階層

Development -> Testing -> Staging -> Production

各環境では、次の点に留意してください。

• 可能な限り本番環境を忠実に再現します
• データとシークレットを分離します
• Infrastructure as Code を使用します

環境変数

variables:
  # Global variables
  APP_NAME: my-app

# Environment-specific
.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）を使用します
• 設定をコードから分離します
• 必要な変数をすべて文書化します

Infrastructure as Code

# Terraform example
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 Tests (Few)
      /----\
     /      \    Integration Tests (Some)
    /--------\
   /          \  Unit Tests (Many)
  --------------

テストの並列化

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 のセキュリティ

シークレット管理

# Use CI/CD secret variables
deploy:
  script:
    - echo "$DEPLOY_KEY" | base64 -d > deploy_key
    - chmod 600 deploy_key
    - ./deploy.sh
  after_script:
    - rm -f deploy_key

ベストプラクティス：

• シークレットを定期的にローテーションします
• 有効期間の短い認証情報を使用します
• シークレットへのアクセスを監査します
• シークレットをログに記録しないでください

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

# Restrict who can run production deploys
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

# Run tests in parallel
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

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

• 可逆性のあるマイグレーションを使用する
• ロールバック手順をテストする
• データの互換性を考慮する
• バックアップを復元する手順を用意する

ドキュメント

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

リポジトリに以下を記載します：

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

ランブック

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

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

継続的な改善

追跡するメトリクス

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

定期レビュー

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