Releases

Ein Release ist ein benannter Zeitpunkt auf einer Site, meistens ein Deploy. Damit lässt sich „ist LCP gestiegen, nachdem wir v2.4.1 ausgerollt haben?" per API-Call beantworten, statt sich durch Charts zu klicken.

Warum das wichtig istCopy Anchor Link

Performance-Regressionen hängen fast immer an einem Deploy. Ohne Release-Marker musst du dir merken, wann was live ging, und dann manuell vergleichen. Mit Markern macht die Analytics-API den Vorher-Nachher-Vergleich in einem einzigen Request.

Wann du sie anfasstCopy Anchor Link

• Bei jedem Deploy. Sauberster Weg: ein POST /sites/{id}/releases aus der CI/CD nach erfolgreichem Deploy.
• Wenn du eine Regression untersuchst. Auf der LCP- oder TTFB-Seite zeigt Vergleichen → Release, gegen das davor ein Release neben dem vorherigen.
• Bei einem Rollback. Auch den als Release taggen; du willst beide Übergänge im Chart sehen.

Wenn du keine Releases taggst, ist nichts kaputt. Das Dashboard funktioniert auch ohne. Dir entgeht nur die Deploy-Korrelation als Abkürzung.

Was auf einem Release stehtCopy Anchor Link

Mehr ist da nicht. Releases sind mit Absicht minimal; wir wollen Korrelation, keine Deploy-Datenbank bauen.

Aus CI/CD taggenCopy Anchor Link

Zuverlässigste Form: ein Schritt am Ende deines Deploy-Jobs:

curl https://api.fastmon.eu/sites/$FASTMON_SITE_ID/releases \
  -H "Authorization: Bearer fm_$FASTMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{ \"version\": \"$DEPLOY_VERSION\", \"released_at\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\" }"

Nimm, was dein CI als Deploy-Version führt: Git-SHA, Tag, Build-Nummer. Egal was, bleib dabei. Sonst zerlegt sich später die Sortierung.

VercelCopy Anchor Link

Deploy-Hook-Command. Die VERCEL_GIT_COMMIT_SHA-Env-Var ist automatisch befüllt.

GitHub ActionsCopy Anchor Link

Letzter Schritt im Deploy-Job, mit ${{ github.sha }} oder ${{ github.ref_name }} als Version.

GitLab CICopy Anchor Link

Eine release-Stage nach der Deploy-Stage, mit $CI_COMMIT_SHA oder $CI_COMMIT_TAG.

Releases vergleichenCopy Anchor Link

Schick das window eines Release als time_range und das vorherige Release als compare_to: { "release_id": … }. Jede Zeile im Ergebnis hat dann ein comparison mit denselben Metriken. Schritte und Beispiel stehen unter Releases vergleichen.

Häufige SzenarienCopy Anchor Link

Continuous DeploysCopy Anchor Link

Tagg jeden Deploy, die Menge ist kein Problem. Die Auswahl unter Vergleichen listet die Releases der letzten 90 Tage, neueste zuerst, ältere erreichst du per ID.

Lang laufende Release-BranchesCopy Anchor Link

Tagge in dem Moment, in dem die neue Version wirklich Traffic abbekommt: beim Flippen des Feature-Flags, beim Umschalten des Canary, beim Umstellen des Load-Balancers. Nicht „Deploy ist durch, gesehen hat's aber noch keiner".

RollbacksCopy Anchor Link

Den Rollback als eigenen Release taggen, gerne mit einer Version wie rollback-v2.4.0. Im Dashboard sollen alle drei Übergänge sichtbar sein: der kaputte Release live, die Regression und der Rollback, der die Metriken wieder einfängt.

Häufige ÜberraschungenCopy Anchor Link

• released_at zählt mehr als id. Sortiert wird nach released_at. Wer rückdatiert, riskiert, dass die Reihenfolge später komisch aussieht.
• Releases sind pro Site. In einem Monorepo, das mehrere Sites ausliefert, musst du jede einzeln taggen, auch wenn der Version-String identisch ist.
• Ein gelöschter Release lässt Vergleiche damit scheitern. Der Endpunkt antwortet mit 404. Schon gerenderte Metriken bleiben unberührt.

VerwandtCopy Anchor Link

• Sites: Releases liegen unter einer Site.
• Analytics-API: compare_to.
• Releases vergleichen: Schritt-für-Schritt-Guide, um CI/CD anzubinden.