変更が増えたとき、公開の仕組みをどう変えるか

worktreeでファイルを分けても、キャッシュ、ツール、サービス、配備先は共有される場合があります。ローカル検証は短いフィードバックに向きますが、統合後の変更を他の仕事の影響なしに確認する役割は別です。

PBG業務基盤のCI見直しでは、永続する実行環境の状態が後続ジョブへ影響し得る点を調べ、一ジョブごとに環境を作り、終了後に破棄する方向へ改めた記録があります。主題は速度より、前の仕事の状態を持ち込まないことでした。

GitHubは自動拡張するself-hosted runnerで、一回のジョブを処理するephemeral runnerを推奨しています。ただし登録解除とホストやディスクの破棄は別です。廃棄、外部ログ、共有キャッシュまで設計します。

PBGの確認では、CI結果が対象revisionと完全に一致することも重視しています。「最近の成功」「同じbranch」では足りません。変更が頻繁なほど、短時間で古くなる成功を取り違えやすいためです。

影響が限定され、検証と復旧が十分で、成果物の経路を信頼できるなら自動公開は合理的です。複数会社のデータや不可逆な変更を扱うなら、許可する場所を狭くする価値が高まります。

操作者を残す方式も、毎回自由にコマンドを組むなら事故を増やします。対象を固定し、差分を確認でき、同じ手順を繰り返せる形にします。PBGは自動化率より、公開内容と責任を追跡できる経路を重視しています。