mcpField
C
checking-deploy-timing

checking-deploy-timing

github.com/posthogクラウド・DevOps95160 回インストール今日更新
リポジトリ

checking-deploy-timing について

checking-deploy-timingは、PostHogの変更が特定の環境やリージョンにいつ反映されたかを確認するスキルです。非表示のデプロイ注釈を基準にし、コミットの祖先関係を調べて対象のマージコミットが含まれることを確認します。

主な機能

  1. 01デプロイ注釈の検索
  2. 02環境とリージョンによる絞り込み
  3. 03デプロイ時刻とマージ時刻の比較
  4. 04デプロイ済みコミットの祖先関係確認
  5. 05本番環境と内部dev環境の区別

活用シーン

  1. 01PRがprod-usに反映された時刻の確認
  2. 02変更がprod-euに反映された時刻の検証
  3. 03デプロイ時刻とメトリクス変化時刻の切り分け
  4. 04後続デプロイに対象コミットが含まれるかの確認

MCP 対応

PostHogの`posthog:annotations-list`ツールでデプロイ注釈を検索します。また、GitHub CLIでプルリクエストとコミットの祖先関係を調べます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/posthog/ai-plugin --skill checking-deploy-timing

インストール後、Claude Code で/checking-deploy-timingを入力して読み込まれたか確認します。

詳細

デプロイされた時期を確認する

PostHog の CI は、コミットが環境に反映されるたびに、プロジェクトにアノテーションとしてデプロイマーカーを書き込みます。これらのアノテーションは hidden_in_user_interface: true に設定されているため UI には表示されず、忘れがちですが、「いつ反映されたか」を確認するための信頼できる情報源です。スタッフからデプロイ時期について尋ねられた場合は、メトリクスやイベント量が変化した時期から推測するのではなく、必ずアノテーションを確認してください（そうした変化から推測すると、データの取り込みの変更とクエリやコードの変更が混同されます）。

デプロイアノテーション

{"search": "deploy"} を指定して posthog:annotations-list で一覧表示します。各デプロイマーカーは次のような形式です。

  • content：Deployed PostHog/posthog@<sha> to <env> — env は prod-us、prod-eu、または dev です
  • creation_type：GIT
  • scope：organization
  • hidden_in_user_interface：true
  • date_marker：デプロイ時刻（UTC）

新しい順に返されます。さらにさかのぼる場合は、offset でページネーションしてください。

ワークフロー

  1. 変更のマージコミットを特定します。 PR を特定し（例：gh search prs --repo PostHog/posthog --author <user> "<keywords>"）、次に gh pr view <n> --repo PostHog/posthog --json number,title,mergedAt,mergeCommit,state を実行します。マージコミットの SHA と mergedAt を確認してください。

  2. 対象環境のマージ前後のデプロイを、古い順に一覧表示します。 ユーザーが尋ねた地域に対応する環境（「米国」なら prod-us、「EU」なら prod-eu）を対象にします。アノテーションは新しい順に返されるため、1 ページ目で最初に見つかった ... to <env> をそのまま選ばないでください。それは 最新の デプロイです。mergedAt 前後のマーカーに達するまで offset を使ってページネーションし、その環境のデプロイを時系列順に並べて、date_marker が mergedAt より後にある最初のデプロイから確認します。手順 3 では、最も早いものから確認してください。

  3. デプロイされたコミットにマージコミットが実際に含まれていることを確認します。 date_marker が後であることは必要条件ですが、十分条件ではありません。マージ直後にデプロイが開始されても、少し古いコミットがビルドされる場合があります。祖先関係を確認してください。

    gh api repos/PostHog/posthog/compare/<merge_sha>...<deployed_sha> --jq '{status,ahead_by,behind_by}'

    status が ahead または identical で、behind_by: 0 なら、デプロイされたコミットにマージコミットが含まれています。これが答えです。behind_by > 0 の場合、このデプロイは変更より前のものです。その環境の次に新しいデプロイ（時系列順で次のもの）に進み、もう一度確認してください。条件を初めて満たすデプロイが、その変更を反映したデプロイです。

  4. 報告します。 質問された地域のデプロイ時刻（および PR／コミット）を伝えてください。関連があれば他の地域についても触れてください。prod-us と prod-eu は通常、数分ずれてデプロイされ、同時ではありません。

注意事項

  • 「米国で稼働中」は prod-us、「EU」は prod-eu を意味します。dev は社内用のステージング環境であり、顧客向けではありません。
  • クエリランナー／読み取りパスの変更の場合、新しい動作はデプロイ後、すべてのデータに遡って適用されます。そのため、イベント量から時期を特定することはできず、デプロイアノテーションだけが頼りになります。データの取り込みに関する変更の場合、新しいプロパティのイベント量は補助的なクロスチェックになりますが、デプロイ時刻の正式な情報源は引き続きアノテーションです。

コメント

Markdown 対応