モジュール 11ターム4 · 本番運用14 ポスター項目

リリース: CI/CD、サプライチェーン、インフラストラクチャ

ログインすると、進捗を複数のデバイスで保存できます。ログインするまでは、このブラウザに保存されます。

なぜ重要なのか

AI を使えば、10 倍の変更を書けるようになります。本番環境への自動化された安全な経路がなければ、それはそのまま 10 倍のインシデントになります。DORA の調査は明確です。スピードと安定性はトレードオフではありません。優れたチームは頻繁にデプロイし、しかも 失敗が少ない。一つひとつの変更が小さく、テストされ、元に戻せるからです。

学習目標

  1. 品質とセキュリティのゲートを備えた CI/CD パイプラインを構築できる。
  2. Docker で再現性のあるコンテナ化ができる。
  3. ソフトウェアサプライチェーンを保護できる（lockfile、SBOM、provenance、slopsquatting）。
  4. feature flag、rolling、canary、blue-green で段階的にリリースできる。
  5. 1 分以内に rollback できる。
  6. インフラをコードとして定義できる。
  7. Kubernetes を使うべきとき（と使うべきでないとき）を判断できる。

レッスン

11.1 パイプライン（6, 107）

すべてのプルリクエストで: インストール（lockfile から）→ lint → 型チェック → ユニットテスト → 結合テスト（コンテナ内の実 DB）→ セキュリティスキャン（シークレット、SAST、依存関係）→ ビルド → プレビューデプロイ → プレビュー上での E2E テスト。 main へのマージ時: ビルドは 1 回だけ行い、同じ成果物 を staging、続いて production にデプロイし、マイグレーションは管理されたステップとして実行し、スモークテストを行い、監視します。

  • ブランチ保護: レビューとチェックの合格を必須にします。誰も（エージェントも）main に直接プッシュしません。
  • ビルドキャッシュ（107） で CI を高速に保ちます（依存関係とレイヤーのキャッシュ、モノレポでのリモートキャッシュ）。CI が遅いと、人はそれを飛ばすようになります。

11.2 Docker（7）

  • マルチステージビルドを使い、小さなベースイメージ（distroless、alpine、slim）を選び、イメージのダイジェストを固定します。
  • root 以外で実行し、イメージやレイヤーにシークレットを入れず、.dockerignore を使います。
  • CI でイメージをスキャンします（Trivy）。ローカル、CI、本番で同じイメージが動きます。「自分のマシンでは動く」の終わりです。

11.3 サプライチェーンと依存関係地獄（108, OWASP A03:2025）

  • lockfile をコミットし、CI では npm ci / frozen なインストールを使います。
  • Slopsquatting: AI ツールは存在しないパッケージを提案することがあり、攻撃者はその名前を先に登録します。新しい依存関係を追加するたびに、実在するか、メンテナンスされているか、実際に使われているか、綴りが正しいかを確認してください。
  • テスト付きの自動アップデート（Dependabot/Renovate）を使います。マイナーアップデートはまとめ、メジャーアップデートはレビューします。
  • 依存関係は最小限にし、プラットフォームと標準ライブラリを優先します。
  • ビルドごとに SBOM（CycloneDX または SPDX）を生成し、provenance/署名（SLSA フレームワーク、Sigstore/cosign、GitHub artifact attestations）を付けます。SBOM を求めるエンタープライズ顧客は増え続けています。
  • GitHub Actions はコミット SHA で固定し、GITHUB_TOKEN の権限は最小限にします。

11.4 段階的デリバリー（51〜55）

  • feature flag（51）: コードを非公開の状態でデプロイし、社内ユーザーに公開し、次に一定の % に、最後に全員に公開します。デプロイとリリースを分離します。古いフラグは片付けます（技術的負債です）。
  • rolling（54）: インスタンスを少しずつ入れ替えます。ほとんどのプラットフォームでのデフォルトです。
  • canary（53）: トラフィックのわずかな % を新バージョンに流し、エラー率とレイテンシを比較して、自動的に昇格させるか中止します。
  • blue-green（52）: 完全な環境を 2 つ用意し、トラフィックを瞬時に切り替えます。瞬時に切り戻すこともできます。
  • rollback（55）: 最も重要なものです。プラットフォームの即時 rollback（Vercel、Cloudflare、Fly、Render）を使うか、前のイメージタグを再デプロイします。練習しておいてください。コードの rollback を安全にするため、データベースマイグレーションは後方互換でなければなりません（03 · データの基礎 の expand and contract）。

11.5 Infrastructure as Code（104, 105）

  • すべて（DNS、バケット、DB、キュー、IAM、アラート）をコードで定義し、PR でレビューし、CI で適用します。本番環境での手作業によるクリック操作は禁止です。
  • Terraform / OpenTofu（105）、Pulumi（TypeScript）、またはプラットフォームの設定ファイルを使います。state はリモートに保存し、ロックします。
  • メリット: 再現性のある環境、監査証跡、再適用による災害復旧。
  • IaC の設定ミスをスキャンします（Checkov、Trivy）。

11.6 Kubernetes、Helm、サービスディスカバリー（8, 9, 106）

  • Kubernetes（8） はコンテナをオーケストレーションします: スケジューリング、自己修復、スケーリング、ローリングアップデート。Helm（106） は K8s アプリをパッケージ化します。サービスディスカバリー（9） により、サービス同士が名前で互いを見つけられます。
  • 率直な助言: 小さなチームなら、マネージドな PaaS（Vercel、Cloudflare、Fly、Render、Railway、Cloud Run、ECS）で、運用負荷のごく一部でメリットの大半を得られます。K8s を採用するのは、サービスが多数ある、プラットフォームチームがある、あるいはエンタープライズ/オンプレミスの要件があるときです。

11.7 環境

ローカル → プレビュー（PR ごと）→ staging（本番相当、匿名化したデータ）→ production。環境ごとに認証情報とアカウントを分けます。デフォルトでは AI エージェントに本番の認証情報を決して持たせません。

Lab 11: 1 日に 10 回リリースする

  1. 上記のパイプライン全体を GitHub Actions で構築します。
  2. SBOM の生成と、依存関係およびコンテナのスキャンを追加し、critical があれば失敗させます。
  3. 新機能をフラグで包み、10%、続いて 100% に公開します。
  4. 意図的に問題のあるデプロイを出し、検知して rollback します。所要時間を計測します。
  5. インフラ（少なくとも DNS、DB、ストレージ、アラート 1 つ）を Terraform/OpenTofu または Pulumi で定義します。

完了の定義

AI プロンプトパック

  • 「lint、型チェック、Postgres サービスコンテナを使ったテスト、gitleaks、Semgrep、依存関係の監査、Trivy スキャン付きの Docker ビルド、SBOM を含む GitHub Actions のワークフローを書いてください。すべての Action を SHA で固定し、最小権限のパーミッションを使ってください。」
  • 「この差分で追加されたすべての依存関係について、レジストリに実在するか、週間ダウンロード数、最終公開日、メンテナー数を確認してください。」