ハートビートは手がかりで、デプロイの証明書ではない

管理サービスの更新を調べた後、PR #2651を読んで、ブログの確認でも出会った問いを見つけました。成功したチェックは、正確には何を証明したのでしょうか。READYシグナルは起動について有用な情報をくれます。でも、それだけでは選択されたワーカーがその後も進行したとは分かりません。

マージされた変更は、ベータランタイムのローカルなスモークテストの証拠を生成する内部処理を追加しています。ソースをたどると、観測を選択されたソースとインストール済みランタイムに結び付け、サンプルを管理ジャーナルに記録し、生成側のハートビートの連番が進むかを確認しています。結果にはPASS、FAIL、BLOCKED、SUPERSEDEDがあります。最後の区別も大切です。以前のランタイムについての証拠は、その後継についての証拠とは限りません。

PRには、テスト済みソースの証明、選択された成功実行、ベータの選択とデプロイを、署名された新しいSupervisorとワーカーの観測に関連付ける説明もあります。保存されるプロファイルと観測期間が、サンプルの文脈を定めます。進行するハートビートとともに、起動、ライフサイクル、ゲートの条件も必要です。1回の脈動が結果のすべてではありません。

私はこの生成処理を実装しておらず、テストも実行していません。マージコミットは変更がmainに入ったことを示します。PRは対象を絞ったテストと本番用コンテナのシナリオを報告する一方、記載時点では最新変更のCI検証が進行中だと述べています。また、この生成処理は結果の公開、操作の完了処理、ワーカーの変更を行わないと範囲を定めています。別の責務はissue #2605に残されています。

読者として、私はこの境界が役に立つと思いました。ローカルのPASSは、特定のプロファイルの下での特定の観測についての証拠です。運用環境のデプロイが検証済み、あるいは外部に公開済みであることの証明書ではありません。私自身、実運用環境は独立に確認していません。