Release‑Prozess — Versionen, Notizen, Migrationen von SDK/Specs, Feature Flags, Rollback

1. Warum der Release‑Prozess für eine ChatGPT App komplexer ist als ein normaler Deploy

Im letzten Teil des Moduls haben wir besprochen, wie man die Qualität und Stabilität der App beobachtet (Logs, Metriken, SLO). Jetzt klären wir, wie man den Release‑Prozess so organisiert, dass diese Metriken nicht bei jedem Deploy zusammenbrechen.

In einer gewöhnlichen Web‑Anwendung ist es relativ einfach: Sie deployen eine neue Version von Backend und Frontend — der Nutzer lädt die Seite neu und arbeitet auf der neuen Version. Wenn etwas kaputtgeht, kann man oft einfach den Deploy zurückrollen.

Bei einer ChatGPT App ist der Stack trickreicher. Es gibt mindestens vier Schichten, die ihre eigenen Lebenszyklen haben:

• Manifest und Tool‑Schema (MCP Tools / OpenAPI);
• Infrastruktur: Next.js‑Anwendung und MCP/Agents/ACP‑Server;
• System‑Prompt und andere Prompts;
• Daten: Product‑Feed, Einstellungen, Konfigurationen.

Das Problem ist, dass das Modell in seiner eigenen „geistigen Welt“ lebt. Der Chat‑Kontext kann sich über Stunden und Tage ziehen. Manifest und Tool‑Beschreibungen werden und gecacht auf der OpenAI‑Seite geladen und aktualisieren sich nicht augenblicklich in allen bestehenden Dialogen. Wenn Sie die Signatur eines Tools ändern (z. B. ein Feld aus dem Input‑Schema entfernen), sendet das Modell in alten Dialogen weiterhin den alten Payload, und Ihr neues Backend wird ihn ablehnen. Ergebnis — 400‑Fehler, seltsame Antworten im Chat und sehr frustrierte Nutzer.

Deshalb ist im Kontext einer ChatGPT App ein „Release“ nicht einfach „einen neuen Docker deployen“. Es ist eine koordinierte Änderung mehrerer Schichten, mit sorgfältigem Versionsmanagement, Feature‑Flags und der Möglichkeit, zurückzurollen.

2. Versionsmatrix: Was überhaupt versionieren

Es ist hilfreich, nicht nur auf die „Version der App 1.3“ zu schauen, sondern direkt auf eine Versionsmatrix nach Schichten. Für GiftGenius sieht das etwa so aus.

giftgenius-app 1.4.2

tools-schema v1.7

prompt v3.1

feed v2, acp v1.3

Beachten Sie: Das sind unterschiedliche Achsen. Sie können eine 1.4.2‑Version der Anwendung ausliefern, in der das Tools‑Schema bei v1.7 bleibt, während der Prompt auf v3.2 wechselt. In den Logs sollte das sichtbar sein; so lässt sich später leichter verstehen, warum nach prompt v3.2 plötzlich die Checkout‑Conversion fiel.

Für Code ist Semantische Versionierung (SemVer) bequem: MAJOR.MINOR.PATCH. MAJOR — Breaking Change, MINOR — neue Features ohne Bruch, PATCH — Bugfixes. Für Schnittstellen‑Versionen (Schema, Prompts) ist die Logik ähnlich: MAJOR signalisiert einen Breaking Change.

Die Version der Tool‑Schnittstelle sollte separat hervorgehoben werden. Für LLM ist das kritisch: Wenn Sie den Vertrag eines Tools ändern, das Modell aber „denkt“, der Vertrag sei noch der alte, beginnt der Spaß. Daher ist die Politik meist so: In MINOR‑Releases fügen wir nur neue optionale Felder hinzu und benennen/entfernen keine alten; Breaking‑Änderungen — nur über ein neues Tool, z. B. suggest_gifts_v2.

Jetzt, da wir die Schichten nach Versionen getrennt haben, schauen wir uns an, wie diese Versionen im Release‑Zyklus „leben“ — von dev bis prod.

3. Basis‑Release‑Flow für GiftGenius

Zuerst einigen wir uns auf die Phasen. Vermutlich haben Sie bereits Umgebungen (aus dem Modul über Deploy), aber jetzt betrachten wir sie durch die Release‑Brille.

Typischerweise unterscheidet man:

• dev — lokale Entwicklung, Dev Mode in ChatGPT, Tunnel;
• staging — so ähnlich wie Prod: gleicher DB‑Typ, gleicher MCP/ACP‑Typ, aber Testdaten und Zahlungen im Sandbox‑Modus;
• prod — Produktionsumgebung, an die die produktive ChatGPT App / der Store‑Eintrag angeschlossen ist.

Der Prozess kann so aussehen:

flowchart TD
  A[Dev: Branch feature/*] --> B[PR → main]
  B --> C[CI: unit + contract + lint]
  C --> D[Deploy to Staging]
  D --> E[Smoke/E2E + manuelle Prüfung]
  E --> F[Deploy to Prod]
  F --> G[Überwachung von Metriken und Logs]

An jeder Stufe fügen wir „Sicherungen“ hinzu. In der dev‑Umgebung kann der Entwickler machen, was er möchte, aber jedes Merge in main triggert CI, das Unit/Contract‑Tests ausführt. Wenn alles ok ist — rollen wir automatisch auf Staging aus. Auf Staging starten wir einen kurzen Satz E2E/Smoke‑Szenarien: z. B. einen vollständigen Flow zur Geschenkfindung und einen „fake“ Checkout über den Test‑Zahlungsanbieter.

Erst danach drücken wir den Deploy‑Knopf für Prod. Idealerweise — mit Versionsmarkierung und Link auf den CHANGELOG. In Prod beobachten wir weiter p95, Error‑Rate und Business‑Metriken (Conversion von Empfehlung zu Checkout). Wenn nach dem Release etwas fällt — brauchen wir einen klaren Rollback‑Plan, den wir unten besprechen.

4. Release Notes und Changelog: Was genau aufschreiben

Ohne Release‑Notizen werden Sie in einem Monat auf ein Diagramm schauen: „Warum ist vor 3 Wochen unser p95 im Checkout doppelt so hoch?“ und sich antworten: „Keine Ahnung, aber wir hatten ein großes Release.“ Keine gute Strategie.

Es gibt in der Regel mindestens zwei Arten von Notizen.

Interner Changelog — technisch. Er ist für Entwickler, SREs und alle, die im Code wühlen. Dort steht, welche Features hinzugekommen sind, welche Bugs gefixt wurden, ob es Breaking Changes gab. Das Format kann man nach Keep a Changelog übernehmen: Sektionen Added, Changed, Fixed, Removed.

Externe Release Notes — menschenlesbare Notizen für Nutzer und für den Store. Dort muss nicht stehen „MCP SDK 0.4 → 0.5 migriert“; besser ist „Empfehlungen für Thanksgiving hinzugefügt“, „Seltener Fehler behoben, durch den manche Geschenke nicht in den Warenkorb gelegt wurden“.

Beispiel eines Ausschnitts aus CHANGELOG.md für GiftGenius:

## [1.4.0] - 2025-11-20
### Added
- Neues Tool `suggest_gifts_v2` mit Unterstützung für Interessen-Tags.
- A/B-Test des neuen System-Prompts (Flag: GG_PROMPT_V3).

### Changed
- Fehlerbehandlung im ACP-Checkout verbessert (freundlichere Meldungen).

### Fixed
- Fehler behoben, durch den Produkte ohne Bild aus den Empfehlungen verschwanden.

Hilfreich ist es, in der Nähe auch die Version des Prompts zu speichern: selbst nur den Commit‑Hash der Datei mit dem System‑Prompt, damit man später nachvollziehen kann: „Aha, nach dem Prompt b3f9c2d haben Nutzer seltener auf „Kaufen“ geklickt.“

5. SDK‑ und Spezifikations‑Migrationen: Leben in einem sich schnell verändernden Ökosystem

Das Ökosystem rund um Apps SDK, MCP und Agents entwickelt sich schnell: neue SDK‑Versionen, Änderungen am MCP‑Protokoll, Updates bei ACP usw. Das ist gut (es entstehen Möglichkeiten), aber auch schmerzhaft: Es kann ebenso schnell brechen.

Versionen pinnen und „nicht am Releasetag aktualisieren“

Die erste einfache Empfehlung: Fixieren Sie die Versionen der Abhängigkeiten. Nicht ^0.4.0, sondern 0.4.0. Für SDKs, die häufig API‑Brüche haben (MCP/Agents/Apps SDK), ist das besonders kritisch. In Untersuchungen zu diesem Thema wird der Effekt „SDK fatigue“ hervorgehoben — Ermüdung durch ständig inkompatible Updates, die besonders jene trifft, die Abhängigkeiten mit gleitenden Versionen gelassen haben (z. B. ^0.4.0) und plötzlich eine Menge Fehler nach einem npm install einfingen.

Mini‑Beispiel:

// package.json (Ausschnitt)
{
  "dependencies": {
    "@modelcontextprotocol/sdk": "0.4.2",
    "@openai/applications-sdk": "0.3.1"
  }
}

Die zweite Empfehlung: Packen Sie in dasselbe Release nicht sowohl Business‑Features als auch große SDK‑Migrationen. Wenn Sie z. B. das MCP SDK von 0.3.x auf 0.4.x aktualisieren müssen, machen Sie besser ein separates technisches Release: zuerst das SDK‑Update, Tests und Stabilisierung, und erst danach — den neuen Checkout‑Flow.

Migrationsstrategie für SDKs

Ein vernünftiger Plan sieht üblicherweise so aus:

In der dev‑Umgebung erstellen Sie einen separaten Branch upgrade/mcp-sdk-0.4. Sie aktualisieren die Abhängigkeit, passen den Code an, führen alle Unit/Contract‑Tests aus und fahren lokal den Hauptflow von GiftGenius im Dev Mode.

Dann deployen Sie diesen Branch auf eine separate Staging‑URL und lassen dort E2E/Smoke‑Tests laufen. Man kann sogar einen kleinen Lasttest machen: 50–100 Aufrufe von suggest_gifts hintereinander.

Wenn alles ok ist — mergen Sie in main, deployen auf das eigentliche Staging, führen erneut die Smoke‑Tests aus, und erst dann — ab nach Prod.

Wenn nicht — gibt es einen offensichtlichen Rollback: einfach diesen Branch nicht mergen oder ihn zurücksetzen. Darin liegt der Sinn, SDK‑Migrationen und Produkt‑Releases zu trennen.

Migrationen von Tool‑Schemata und APIs

Der unangenehmste Teil — Interface‑Änderungen: Das Modell erfährt nicht sofort davon. Untersuchungen betonen hier eine wichtige Regel: „Erweitern, aber nicht brechen“ (additive‑only). Wenn Sie in suggest_gifts das neue Argument interests: string[] hinzufügen müssen, machen Sie es optional statt verpflichtend; alte Szenarien funktionieren dann weiter.

Beispiel einer Evolution einer Zod‑Schema für Eingabedaten:

// v1
const suggestGiftsInputV1 = z.object({
  recipientName: z.string(),
  budget: z.number()
});

// v1.1 (optionale Felder hinzugefügt)
const suggestGiftsInputV1_1 = suggestGiftsInputV1.extend({
  interests: z.array(z.string()).optional(),
  occasion: z.string().optional()
});

Beachten Sie: Wir fassen bestehende Felder nicht an, wir erweitern nur.

Wenn Sie den Vertrag wirklich brechen müssen (z. B. budget durch minBudget + maxBudget ersetzen), erstellen Sie besser ein neues Tool suggest_gifts_v2 und geben in der Beschreibung an, dass es sich um eine verbesserte Version handelt. Die alte API kann als deprecated bestehen bleiben und später abgeschaltet werden, wenn Sie sicher sind, dass Modell und Nutzer umgezogen sind.

Datenmigrationen: Product‑Feed und ACP

Wir haben bereits über SDK‑ und Tool‑Schema‑Migrationen gesprochen. Der Product‑Feed ist ebenfalls ein Vertrag. Wenn Sie das Format von SKU, Währungen, Lokalisierungen ändern, muss das koordiniert erfolgen: Schema des Feeds aktualisieren, Verarbeitung in MCP/ACP anpassen und alle Pre‑Prozessoren. In der Commerce‑Dokumentation für ChatGPT Apps wird betont, dass Fehler im Feed (kaputte Felder, Duplikate, seltsame Preise) die Qualität der Empfehlungen selbst bei perfektem Code zerstören können.

Typischer Ansatz:

1. Zuerst fügen Sie die neuen Felder im Feed‑Schema als optional hinzu und bringen GiftGenius bei, sie zu nutzen, falls vorhanden.
2. Dann aktualisieren Sie die Pipeline, die den Feed erstellt, sodass diese Felder befüllt werden.
3. Sie starten den Feed‑Validator (Contract‑Tests auf Daten) und verlassen sich erst danach in der Logik auf diese Felder.

6. Feature Flags: Deploy vom Release trennen

Feature‑Flags — eines der wichtigsten Überlebenswerkzeuge in der Welt der ChatGPT App. Die Grundidee ist einfach: Sie deployen Code, aktivieren die neue Funktionalität aber nicht zwingend sofort. Zunächst lebt sie „unter einem Flag“ — nur für Entwickler aktiviert, oder für 1% der Nutzer, oder komplett ausgeschaltet.

Das ist besonders wichtig, wenn:

• Sie einen neuen Empfehlungsalgorithmus ausrollen;
• Sie den System‑Prompt ändern (was das Modellverhalten radikal ändern kann);
• Sie ein teures oder langsames Tool anschließen;
• Sie mit einem neuen Checkout‑Flow experimentieren.

Einfaches Flag über Umgebungsvariablen

Im Minimalfall kann man ein Feature‑Flag über eine Umgebungsvariable umsetzen:

// lib/features.ts
export const isNewRecoEnabled =
  process.env.NEXT_PUBLIC_GG_NEW_RECO === "1";

Im Code des MCP‑Tools können Sie das so verwenden:

if (isNewRecoEnabled) {
  return runNewRecoAlgorithm(input);
}
return runOldRecoAlgorithm(input);

Vorteil dieses Ansatzes — Einfachheit. Nachteil — Flags in der Laufzeit umzuschalten ist schwieriger: Man muss ein neues Environment deployen oder zumindest neu initialisieren.

Zentraler Helper mit Kontext

Ein etwas reiferer Ansatz — einen zentralen Helper zu haben, der nicht nur globale Flags berücksichtigt, sondern auch den Nutzerkontext (Tenant, Segment, A/B‑Gruppe).

// lib/featureFlags.ts
type Feature = "new-reco" | "checkout-v2";

type Context = { userId: string; tenantId?: string };

export function isFeatureEnabled(
  feature: Feature,
  ctx: Context
): boolean {
  // hier kann Logik stehen: env, DB, externer Flag-Service
  if (feature === "new-reco") {
    return process.env.GG_NEW_RECO === "1";
  }
  return false;
}

Im MCP‑Handler:

const enabled = isFeatureEnabled("new-reco", { userId });
const result = enabled
  ? await runNewReco(input)
  : await runOldReco(input);

Wenn Sie irgendwann einen externen Flag‑Service (LaunchDarkly, Statsig etc.) anschließen, reicht es, die Implementierung von isFeatureEnabled zu ändern, nicht den gesamten Code.

Beispielszenarien für GiftGenius

A/B‑Test des System‑Prompts. Sie erstellen PROMPT_V2 und schalten ihn nur für 10% der Nutzer mit tenantId in einer bestimmten Liste frei. Die MCP‑Tools und das Widget ändern sich nicht, und Sie vergleichen die Conversion.

Kill‑Switch für ein teures Tool. Angenommen, Sie haben ein Tool gebaut, das eine komplexe externe Anfrage macht (z. B. an ein Empfehlungs‑ML‑Modell, das teuer ist). Wenn dieser externe Dienst ausfällt oder plötzlich teurer wird, wollen Sie ihn in einer Sekunde abschalten können, ohne GiftGenius komplett zu stoppen. Ein Feature‑Flag ist der einfachste Weg.

Schrittweiser Rollout des neuen Checkout‑Flows. Checkout v2 schalten Sie zunächst nur für Mitarbeitende und ein paar vertrauenswürdige Kunden frei. Wenn die Metriken ok sind — erweitern Sie das Publikum, bis es für alle aktiviert ist.

7. Rollback: Wie man schnell zurückrollt, wenn es brennt

Selbst bei perfekten Tests und Flags geht etwas schief. Wichtig ist, eine klare Strategie zu haben: Was tun Sie in den ersten 5–15 Minuten, nachdem Sie einen Fehler‑Spike oder Metrik‑Einbruch gesehen haben?

Schneller Rollback von Code

Liegt das Problem an einem rein technischen Bug (NPE, falsche Variable, falsche URL eines externen Dienstes), reicht es meist, den Deploy auf die vorherige Version zurückzurollen. Bei Vercel gibt es z. B. einen sofortigen Rollback auf den vorherigen Deployment.

Ihre Aufgabe — immer zu wissen, welcher Deployment welcher Version entspricht und wie man ihn zurückrollt. Idealerweise steht das im README für On‑Call: „Wenn nach Release 1.4.0 alles brennt, auf Deployment X zurückrollen.“

Der zweite schnelle Hebel — Feature‑Flags. Wenn nur das neue Feature (checkout-v2) kaputt ist, ist es einfacher, es per Flag auszuschalten, als direkt das ganze Release zurückzurollen.

Riskante Änderungen: Manifeste und Schemata

Mit Manifesten und Schemata ist es schwieriger. Wenn Sie im Store ein neues Manifest mit falschem Tool‑Schema veröffentlicht haben und es bereits von OpenAI genehmigt wurde, kann ein Rollback Tage dauern. Der einfache Grund: Jede Manifest‑Änderung durchläuft ebenfalls OpenAI‑Review. In Analysen zu verschiedenen Stores wird direkt gesagt, dass Änderungen am Manifest und an Schemata „riskante“ Releases sind, die besonders sorgfältig vorbereitet und getestet werden müssen.

Daher besser trennen:

• sichere Releases: Änderungen am MCP/Next.js‑Code, Prompt‑Anpassungen, neue Features hinter Flags;
• riskante Releases: Änderungen an der Tool‑Liste, den Input/Output‑Schemata, ACP‑Verträgen.

„Riskante“ Releases sollten separat ausgerollt werden, mit zusätzlichen Checks und ggf. zunächst nur über Dev Mode und eine Staging‑App (ohne Veröffentlichung im Store).

Rollback von Daten und Feed

Mit Daten ist es noch komplizierter (und schmerzhafter). Wenn Sie den Product‑Feed auf ein neues Schema migriert und dabei alte Felder entfernt haben, ist der Rückweg nicht immer trivial. Daher müssen Datenmigrationen idempotent und reversibel sein: Entweder behalten Sie eine alte Kopie oder führen die Migration in zwei Schritten durch (zuerst Daten duplizieren, dann das Lesen umschalten).

Ein einfacher Ansatz — alte und neue Felder eine Zeitlang parallel halten und die Möglichkeit haben, per Feature‑Flag zwischen ihnen umzuschalten. Wenn etwas ausfällt — schalten Sie einfach zurück auf das alte Lesen.

8. Mini‑Design des Release‑Prozesses für GiftGenius

Fassen wir alles zusammen, was wir oben besprochen haben (Versionen, SDK‑Migrationen, Feature‑Flags, Rollback), in einem praktischen Szenario.

Stellen wir uns vor, Sie arbeiten am Release 1.4.0, in dem:

• ein neues Tool suggest_gifts_v2 mit erweitertem Input hinzugefügt wird;
• ein neuer System‑Prompt für einen Teil der Nutzer aktiviert wird;
• das MCP SDK von 0.3 → 0.4 aktualisiert wird;
• das Format des Product‑Feeds geändert wird (Feld tags hinzugefügt).

Ein vernünftiger Plan sähe so aus.

Zuerst ein separates technisches Release 1.3.1: MCP‑SDK‑Update + minimale Code‑Anpassungen, ohne Schema‑ oder Feature‑Änderungen. CI laufen lassen, Staging, Smoke‑Tests. Wenn alles stabil ist — leben Sie so ein paar Tage.

Dann der Branch feature/reco-v2. Darin fügen Sie suggest_gifts_v2 als neues Tool hinzu (das alte suggest_gifts bleibt). Sein Input‑Schema wird nur additiv um neue optionale Felder erweitert. Sie bereiten den neuen System‑Prompt vor, kapseln ihn aber hinter dem Flag GG_PROMPT_V3. Im ACP/Feed fügen Sie das neue Feld tags als optional hinzu, und die Verarbeitung gestalten Sie so, dass bei dessen Fehlen alles weiter funktioniert.

In CI fügen Sie einige neue Contract‑Tests hinzu: dass suggest_gifts_v2 alten und neuen Payload akzeptiert, dass ein Feed mit tags valide ist, aber alte Einträge ohne tags den Server ebenfalls nicht brechen.

Nach dem Merge in main:

• CI führt Unit/Contract‑Tests aus;
• auf Staging laufen 1–2 E2E‑Szenarien über das neue Tool;
• Sie aktivieren den neuen Prompt und das Tool nur für einen Test‑Tenant über ein Feature‑Flag.

Sie beobachten die Metriken: p95 des Tools, Error‑Rate, Conversion zum Checkout. Wenn alles ok ist — erweitern Sie das Flag auf mehr Nutzer. Und erst danach, wenn Sie von der Stabilität überzeugt sind, aktualisieren Sie das Manifest für den Store (falls nötig) und die Promo‑Beschreibung der App.

Wenn unterwegs etwas bricht — wissen Sie, wie Sie zurückrollen: entweder schalten Sie das Flag aus, rollen den Deployment zurück oder — im Extremfall — rollen die Manifest‑Version zurück (das ist allerdings der Fall, den man am besten ganz vermeidet).

9. Typische Fehler im Release‑Prozess einer ChatGPT App

Fehler Nr. 1: eine abstrakte „App‑Version“ statt einer Versionsmatrix.
Wenn Sie nur „GiftGenius v1.4“ haben, aber nirgends die Versionen des Tools‑Schemas, der Prompts und des Product‑Feeds festgehalten sind, können Sie später nicht beantworten: „Nach welcher Änderung ist unser Checkout eingebrochen?“ Trennen Sie Versionen nach Schichten und loggen Sie sie in strukturierten Logs.

Fehler Nr. 2: Breaking‑Änderungen an Tools ohne neuen Namen/Version.
Der schmerzhafteste Fall: Sie benennen ein Feld im Input‑Schema um oder löschen es, ohne den Tool‑Namen zu ändern. In alten Chats sendet das Modell weiterhin den alten Payload, das Backend liefert 400, GPT beginnt „zu halluzinieren“, Nutzer verstehen nichts. Jede brechende Änderung machen Sie über ein neues Tool (foo_v2) oder über eine neue API‑Version, und die alte Schnittstelle bleibt für eine Übergangszeit bestehen.

Fehler Nr. 3: SDK‑Update „auf dem Weg“ zum Feature.
Klassiker: Sie fügen ein neues Business‑Feature hinzu und aktualisieren unterwegs @modelcontextprotocol/sdk von 0.3 auf 0.5 „damit alles schön frisch ist“. Wenn dann etwas bricht, ist unklar, ob der neue Code, das neue Schema oder das neue SDK schuld ist. SDK‑Migrationen besser als separate Tech‑Releases mit klarem Testplan und Rollback‑Möglichkeit durchführen.

Fehler Nr. 4: fehlende Feature‑Flags und Instant‑Kill‑Switches.
Einen neuen Empfehlungsalgorithmus sofort auf 100% der Nutzer auszurollen, ist lustig, bis er komische Ergebnisse liefert oder einen externen Dienst lahmlegt. Ohne Feature‑Flag bleibt als einziger Hebel der Komplett‑Rollback des Releases, der nicht nur das neue Feature, sondern auch ein Dutzend harmlose Verbesserungen zurückdreht. Machen Sie wenigstens einfache Flags über env oder eine kleine Konfig.

Fehler Nr. 5: Hoffnung auf ein „sofortiges“ Manifest‑Update.
Ein verbreitetes Missverständnis ist die Annahme, dass das Modell sofort von einem neuen Schema erfährt, sobald Sie Tools oder openapi.yaml ändern. In der Praxis werden Manifest und Tool‑Beschreibungen gecacht und können in bereits geöffneten Chats lange weiterleben. Das zu ignorieren führt zu subtilen Bugs: In neuen Chats funktioniert alles, in alten — fällt es aus. Planen Sie Schema‑Änderungen mit diesem Verhalten ein und testen Sie sie über Dev Mode und Staging, bevor Sie in den Store ausrollen.

Fehler Nr. 6: kein klarer Rollback‑Plan und keine Release‑Dokumentation.
Wenn in Ihrem Team niemand beantworten kann „Wie rollen wir in 5 Minuten zurück?“, „Welche Version rollen wir zurück?“, „Wie kehren wir zum alten Feed‑Schema zurück?“ — dann haben Sie praktisch keinen Rollback. Für On‑Call sollte es ein kurzes, aber konkretes Playbook geben: welche Knöpfe zu drücken sind, welche Variablen zu ändern sind und wo zu prüfen ist, dass der Rollback wirksam war.

Fehler Nr. 7: „stumme“ Releases ohne Release Notes und ohne Verknüpfung mit Metriken.
Releases ohne irgendeinen Changelog auszurollen bedeutet, in ein paar Monaten im Rätselmodus zu leben. Wenn der p95 plötzlich steigt und die Conversion fällt, werden Sie raten: „Was hat sich damals überhaupt geändert?“ Die Gewohnheit, wenigstens minimale Release‑Notizen zu schreiben und sie mit Deploy‑Daten und Versionen zu verknüpfen, erleichtert nicht nur die Qualitätsprüfung, sondern das Leben des gesamten Teams.