ci-cd-patterns

CI/CD パターン

GitHub Actions、PR の自動化、デプロイのワークフローに関するパターンです。

使用する場面

• GitHub Actions のワークフローを設定または修正するとき
• PR のチェック（lint、テスト、ビルド）を自動化するとき
• デプロイパイプラインを設定するとき
• PR のステータスを監視し、不安定な CI を再実行するとき
• 複数環境へのデプロイ（dev、staging、prod）を設定するとき

GitHub Actions --- 一般的なパターン

基本的な CI ワークフロー

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test

PR チェックワークフロー

name: PR Check
on: pull_request

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew ktlintCheck

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew test

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew build

PR を見守るパターン

CI を通じて PR を監視し、よくある失敗に対処します。

1. CI のステータスを確認する --- gh pr checks <number>
2. 失敗の種類を特定する --- 不安定なテスト、lint エラー、ビルド失敗
3. 修正してプッシュする --- lint／ビルドエラーの場合は、ローカルで修正してプッシュします
4. 不安定なテストを再実行する --- ワークフローを再実行します：gh run rerun <run-id> --failed
5. マージコンフリクトを解決する --- 対象ブランチにリベースします
6. 自動マージを有効にする --- gh pr merge <number> --auto --squash

すぐに使える GitHub Actions YAML テンプレートについては、workflows.md を参照してください。

デプロイチェックリスト

デプロイする前に：

• すべての CI チェックに合格している
• マージコンフリクトがない
• データベースのマイグレーションをレビュー済み（該当する場合）
• 対象環境に環境変数が設定されている
• ロールバック計画を確認済み

注意点

• キャッシュを使うと実行ごとに数分短縮できます。 依存関係は必ずキャッシュしてください（actions/cache またはキャッシュを有効にした actions/setup-java）。Gradle のコールドビルドには 3〜5 分かかりますが、キャッシュを使うと 30 秒で済みます。
• needs: は依存関係を順次実行にします。 指定しない場合、すべてのジョブが並列実行されます。needs: [lint, test] を使うと、チェックの完了後にビルドが実行されます。
• シークレット名では大文字と小文字が区別されます。 secrets.DB_PASSWORD と secrets.db_password は別のものです。Settings > Secrets に表示されている正確な名前を使用してください。
• actions/checkout@v3 は使わず、v4 を使用してください。 v3 は非推奨の Node 16 を使用します。v4 は Node 20 を使用します。
• 不安定なテストは、単に再実行するのではなく原因を調査する必要があります。 同じテストのためにワークフローを 2 回以上再実行した場合は、そのテストを修正してください。よくある原因は、競合状態、時間に依存するアサーション、共有されたテスト状態です。
• CI のレビュー中に強制プッシュすると、チェック一式がリセットされます。 CI が完了するまで強制プッシュを待ってください。そうしないと、ランナーの実行時間が無駄になります。

ルール

• すべての PR はマージ前に CI に合格する必要があります
• ドキュメントのみの変更でない限り、CI チェック（[skip ci]）をスキップしないでください
• ワークフロー全体を 10 分以内に収めてください
• 複数バージョンのテストにはマトリックスビルドを使用してください
• シークレットは GitHub Secrets に保存し、コードには決して含めないでください