CI/CD は『安全に速くリリースする』ためのインフラ
CI/CD は単なる自動化ではなく、リリースの安全性と速度を両立する基盤です。本記事では編集部の視点で、GitHub Actions を中心とした設計を公開情報をもとに整理します。フィーチャーフラグ実践 もご参考に。
パイプラインの基本構成
(1) Lint / Format：PR で即座にフィードバック。(2) 型チェック：tsc / mypy。(3) 単体・結合テスト：並列実行。(4) E2E テスト：Playwright 等。(5) ビルド+成果物保存：再利用可能に。(6) デプロイ：環境ごとに承認制御。
GitHub Actions の主要パターン
(1) jobs と並列実行：CPUコア活用。(2) matrix strategy：複数バージョン/環境を並列。(3) composite action：再利用可能なステップ集約。(4) reusable workflow：他リポからも呼べる workflow。(5) environment 機能：本番デプロイの承認制御。
パイプライン最適化
(1) キャッシュ活用：npm / pnpm / Docker レイヤー。(2) 差分実行：変更ファイルから影響範囲を判定。(3) 並列度向上：マトリクスを最大化。(4) Self-hosted runner：固定インフラで高速化。(5) Artifact 共有：ビルドを下流で再利用。5分以内のフィードバックを目標にすると開発体験が大きく改善します。Monorepo 設計 でビルド差分も組み合わせて。
シークレットと権限管理
(1) Repository / Environment Secrets：スコープ分離。(2) OIDC で AWS/GCP に認証：長期キー禁止。(3) GITHUB_TOKEN の権限最小化：read-only を default に。(4) SARIF アップロード：セキュリティスキャン結果。(5) Dependabot / Renovate：依存更新の自動化。認証・認可実践 も合わせて。
デプロイ戦略
(1) Blue/Green：環境切替で即時ロールバック。(2) Canary：トラフィックを段階的に。(3) Feature Flag 併用：コード/トラフィック分離。(4) 本番手動承認：environment review。(5) ロールバック手順：自動化必須。フィーチャーフラグ実践 も合わせて。
失敗しがちなパターン
(1) CI が遅すぎてレビューが滞る。(2) フレーキーテスト放置：信頼性低下。(3) 秘密情報のログ漏洩。(4) 本番デプロイの過剰自動化：事故時の影響大。(5) workflow のコピペ運用：管理破綻。対策は、(1)並列+キャッシュで10分以内、(2)retries+原因究明、(3)set-secret-output、(4)Canary+手動承認、(5)reusable workflow、です。