AI駆動開発の実運用ノート

本編の目次 › 第5部 デプロイ・運用・移植 › 再現と AI コストの統治

AI駆動開発の実運用ノート No.126バッチデプロイを起動して、見張らずに完了を確認する

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第5部「デプロイ・運用・移植」から、「再現と AI コストの統治」のお話です。

再現手順

バッチデプロイ——キューを一括で検証環境へ

本資料で Keihi に積んだ変更(差戻し機能・第4部のフック)を1件ずつではなく、キューに貯めて一括で反映・一括で検証する。

手順
  1. マージ済みで未検証の変更を一覧にする(これが「検証待ちキュー」)
  2. make dev で全コンテナを一括で再ビルド・再作成する
  3. make logs で healthy を確認してから、キューの全項目をまとめてブラウザ検証
  4. 検証結果を各イシューにまとめて記録し、そこで初めて Done にする
確認できること
  • 反映前に一括で実機検証している——「バッチだから後で」が無いこと
  • 題材プロジェクトでは非同期起動 + 完了マーカーのポーリングで、接続が切れても死なない形にした

全5部を通じて、Keihi にいくつも機能をマージしてきました。 それを1件ずつではなく、キューに貯めて一括で検証環境へ運びます。

ここで注目してほしいのは、デプロイを起動したあと、その処理を「見張らない」ことです。

セッションから切り離して走らせ、完了マーカーを後で確認しに行くだけです。 終わったかどうかはAIの報告ではなく、置かれたマーカーが答えます。

SSH切断の事故から得た設計が、そのままここで効いています。 だから、待っている間、人は別の作業に移れます。手順は開発フローマニュアルの該当章にあります。

つづく