Vérifier quand quelque chose a été déployé

PostHog's CI écrit un marqueur de déploiement dans le projet sous la forme d'une annotation chaque fois qu'un commit est livré à un environnement. Ces annotations ont hidden_in_user_interface: true, donc elles ne s'affichent pas dans l'UI et sont faciles à oublier — mais elles sont la source de vérité pour « quand est-ce que c'est sorti ». Vérifiez-les toujours quand le staff pose des questions sur le timing du déploiement, plutôt que d'en déduire à partir de quand une métrique ou un volume d'événement a changé (cela confond un changement de capture avec un changement de query/code).

Les annotations de déploiement

Listez-les avec posthog:annotations-list en utilisant {"search": "deploy"}. Chaque marqueur de déploiement ressemble à :

• content: Deployed PostHog/posthog@<sha> to <env> — env est prod-us, prod-eu, ou dev
• creation_type: GIT
• scope: organization
• hidden_in_user_interface: true
• date_marker: l'heure du déploiement (UTC)

Elles sont retournées du plus récent au plus ancien ; paginez avec offset si vous avez besoin de remonter plus loin.

Workflow

1. Trouvez le commit de fusion du changement. Identifiez la PR (par exemple gh search prs --repo PostHog/posthog --author <user> "<keywords>"), puis gh pr view <n> --repo PostHog/posthog --json number,title,mergedAt,mergeCommit,state. Notez le SHA du commit de fusion et mergedAt.

2. Listez les déploiements de l'environnement cible autour de la fusion, du plus ancien au plus récent. Faites correspondre la région demandée par l'utilisateur (prod-us pour « les États-Unis », prod-eu pour « l'UE »). Les annotations reviennent du plus récent au plus ancien, donc ne prenez pas simplement le premier match ... to <env> de la page 1 — c'est le déploiement le plus récent. Paginez (avec offset) jusqu'à atteindre des marqueurs autour de mergedAt, puis considérez les déploiements de cet environnement dans l'ordre chronologique, en commençant par le premier dont le date_marker est après mergedAt. Vérifiez-les du plus ancien au plus récent à l'étape 3.

3. Confirmez que le commit déployé contient réellement le commit de fusion. Un date_marker plus tardif est nécessaire mais pas suffisant — un déploiement peut se déclencher juste après la fusion mais construire un commit légèrement plus ancien. Vérifiez l'ascendance :

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

   behind_by: 0 avec un status ahead ou identical signifie que le commit déployé inclut la fusion — c'est votre réponse. Si behind_by > 0, ce déploiement est antérieur au changement ; passez au prochain déploiement plus récent de cet environnement (le suivant chronologiquement) et revérifiez. Le premier déploiement qui passe le test est celui qui a livré le changement.

4. Signalez l'heure du déploiement (et la PR/commit) pour la région demandée. Mentionnez les autres régions si pertinent — prod-us et prod-eu se déploient généralement à quelques minutes d'intervalle mais pas simultanément.

Notes

• « Live aux États-Unis » = prod-us ; « l'UE » = prod-eu. dev est l'environnement de staging interne, pas orienté client.
• Pour un changement query-runner / read-path, le nouveau comportement s'applique rétroactivement à toutes les données une fois déployé — donc vous ne pouvez pas le chronométrer à partir du volume d'événement, seulement à partir de l'annotation de déploiement. Pour un changement de capture, le volume d'événement pour la nouvelle propriété est une vérification croisée secondaire, mais l'annotation reste toujours l'heure de déploiement faisant autorité.