Plan für schrittweises Rollout
Erstellt einen strukturierten Release-Plan nach dem Idira Gradual Release Framework: Signale aus dem PRD ableiten, den Release-Pfad klassifizieren, Ringe zuordnen, den R3-Kohortenplan erstellen und Schritte für LaunchDarkly konfigurieren.
Schritt 1 – PRD lesen und Signale ableiten
Lesen Sie das PRD vollständig. Leiten Sie jedes der folgenden Signale aus dem Inhalt ab. Fragen Sie den PM nicht nach Dingen, die Sie selbst ermitteln können.
| Signal | Worauf achten |
|---|---|
| NFI | „NFI”-Label, „neue Funktion”, „bisher nicht verfügbar”, völlig neue Fähigkeit ohne Vorgängerversion |
| Auswirkung | Umfang der betroffenen Benutzer/Mandanten, „kritischer Pfad” / „Kern-Workflow”-Sprache, Datensensitivität, Risiko von Datenverlust oder Dienstunterbrechung |
| Rollback-Komplexität | Schema-Migrationen, Datenschreibvorgänge, Abhängigkeiten von Drittanbietern, erforderliche Kundenkommunikation, irreversibler Zustand → Koordiniert oder Irreversibel. Nur Flag umschalten → Einfach. Wenn nicht erwähnt → muss nachfragen |
| Regionseinschränkungen | DSGVO, FedRAMP, Datenresidenz, regionsspezifische Anforderungen, „beginnend mit [Region]”, „nur [Region]”, „[Region] zuerst”, „beschränkt auf [Region]” |
| Serviceeinschränkungen | Benannte Dienste, Integrationen oder Komponenten, von denen die Funktion abhängt oder die sie ändert |
| Bereitschaft für frühe Tester | „bereit für QA”, Sprint-Abschlussdaten, Alpha-/Beta-Termine – wann die Funktion stabil genug für die erste externe Nutzung ist |
| Ziel-GA | Verbindliches Launch-Datum, OKR-Deadline, Release-Meilenstein |
Nach dem Lesen präsentieren Sie Ihre Ableitungen – stellen Sie keine offenen Fragen. Für jedes Signal, das nicht im PRD gefunden wurde, markieren Sie es mit ❓ und stellen Sie am Ende eine gezielte Frage:
Basierend auf dem PRD habe ich dieses Release wie folgt interpretiert:
- NFI: [Ja / Nein – Begründung] oder ❓ Nicht klar aus PRD
- Auswirkung: [Hoch / Mittel / Niedrig – Begründung] oder ❓ Nicht klar aus PRD
- Rollback: [Einfach / Koordiniert / Irreversibel – Begründung] oder ❓ Nicht erwähnt
- Regionseinschränkungen:[Keine / Liste – Begründung] oder ❓ Nicht erwähnt
- Serviceeinschränkungen:[Keine / Liste – Begründung] oder ❓ Nicht erwähnt
- Bereit für frühe Tester: [Datum – Begründung] oder ❓ Nicht im PRD gefunden
- Ziel-GA: [Datum – Begründung] oder ❓ Nicht im PRD gefunden
Stellen Sie dann nur die ❓-Fragen in diesen exakten Formulierungen:
- Rollback nicht erwähnt → „Gibt es einen Rollback-Plan? Optionen: (1) Einfach – einfaches Flag-Umschalten, sofortiger Rückgang. (2) Koordiniert – erfordert Datenmigration, Skript oder Kundenkommunikation. (3) Noch nicht definiert – Rollback-Strategie muss noch entworfen werden.”
- Auswirkung nicht klar → „Wie würden Sie die Auswirkung auf den Kunden beschreiben, falls etwas schiefgeht? Hoch (betrifft Kern-Workflows oder viele Mandanten), Mittel (beschränkt auf einen bestimmten Dienst oder eine Teilmenge) oder Niedrig (kosmetisch / leicht umkehrbar)?”
- Bereit für frühe Tester nicht gefunden → „Wann wird die Funktion bereit für frühe Tester sein, um mit der Validierung zu beginnen?”
- Ziel-GA nicht gefunden → „Was ist das Ziel-GA-Datum oder der Zeitrahmen?”
- Region nicht erwähnt → „Gibt es Regionseinschränkungen? Zum Beispiel: Beginn mit einer bestimmten Region (EMEA, US, APAC) vor der globalen Expansion?”
Gehen Sie nicht von Werten aus. Fragen Sie nicht nach Signalen, die Sie bereits aus dem PRD ermittelt haben.
Schritt 2 – Release-Pfad klassifizieren
NFI = Ja → HIGH-TOUCH
ODER Auswirkung = Hoch
ODER Rollback = Irreversibel
Auswirkung = Mittel → STANDARD
ODER Rollback = Koordiniert
Alle anderen → LIGHTWEIGHT
Schritt 3 – Erforderliche Ringe zuordnen
| Pfad | Pflichtringe | R&D besitzt | PM besitzt |
|---|---|---|---|
| LIGHTWEIGHT | R0 → R4 | R0 | R4 |
| STANDARD | R0 → R3 → R4 | R0 | R3, R4 |
| HIGH-TOUCH | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 Interne QA – Entwicklungs-/QA-Umgebungen
- R1 Customer Zero / Dogfooding – interne Teams
- R2 Customer One – ausgewählte Early-Access-Kunden (über NFI-Prozess)
- R3 Production Canary – Test-Mandanten → Live-Kohorten über LaunchDarkly-Flags
- R4 General Availability – alle berechtigten Produktionsmandanten
Schritt 4 – R3-Kohortenplan erstellen (nur Standard & High-Touch)
R3 beginnt immer zuerst mit Test-Mandanten. Dann sequenziell Live-Mandanten nach ARR:
| Welle | Kumulativ % | Targeting |
|---|---|---|
| 0 | — | Test-Mandanten (kundengekaufte Sandboxes) |
| 1 | 5 % | Niedrigster ARR, kleine Mandantenanzahl |
| 2 | 15 % | Niedrig-mittlerer ARR |
| 3 | 35 % | Mittlerer ARR |
| 4 | 65 % | Mittlerer-hoher ARR |
| 5 | 100 % | Alle verbleibenden berechtigten Mandanten |
Anpassungen:
- Serviceeinschränkungen → Service-Filter-Targeting pro Welle hinzufügen
- Regionseinschränkungen → Regionsfilter zu frühen Wellen hinzufügen, für Welle 4–5 entfernen
- Kurzer Zeitrahmen → Wellen zusammenlegen (z.B. 5 % → 35 % → 100 %)
- Hohe ARR-Sensitivität → Mandanten mit hohem ARR bis Welle 4 mit verlängerter Backzeit zurückhalten
Für jede Welle angeben: %, Kohortenbeschreibung, Go/No-Go-Gate (Metrik + Backzeit), Verantwortlicher. Go/No-Go-Gates sind obligatorisch – niemals weglassen. Wenn das PRD Erfolgsmetriken definiert, diese verwenden. Wenn nicht, Standardwerte anwenden: Anmelde-/Funktionserfolgsrate ≥ 99,5 %, Fehlerratendelta < 0,1 %, p99-Latenzregression < 5 %, Support-Ticket-Spitze < 3 pro 1.000 Mandanten, minimale Backzeit 48 h für frühe Wellen und 1 Woche für Wellen mit hohem ARR.
Schritt 5 – Vollständigen Release-Plan ausgeben
Erstellen Sie den Plan mit dieser Vorlage:
# Plan für schrittweises Rollout – [Funktionsname]
**Release-Pfad:** [LIGHTWEIGHT / STANDARD / HIGH-TOUCH]
**Frühester Start:** [Datum] | **Ziel-GA:** [Datum]
---
## Wie ich dieses Release interpretiert habe
| Signal | Wert | Begründung |
|--------|------|------------|
| NFI | Ja/Nein | [eine Zeile] |
| Auswirkung | Hoch/Mittel/Niedrig | [eine Zeile] |
| Rollback | Einfach/Koordiniert/Irreversibel | [eine Zeile] |
| Regionseinschränkungen | Keine / [Liste] | [eine Zeile] |
| Serviceeinschränkungen | Keine / [Liste] | [eine Zeile] |
---
## Erforderliche Ringe
| Ring | Stufe | Besitzer | Eintrittskriterium | Austrittskriterium |
|------|-------|----------|--------------------|--------------------|
| R0 | Interne QA | R&D | Merge zu main | QA-Freigabe |
| R1 | Dogfooding | R&D | R0 abgeschlossen | Interne Freigabe *(nur High-Touch)* |
| R2 | Customer One | PM | NFI-Prozess abgeschlossen | Kundenfeedback geprüft *(nur High-Touch)* |
| R3 | Production Canary | PM | R2 abgeschlossen | 100 %-Welle stabil |
| R4 | General Availability | PM | R3 100 %-Welle abgeschlossen | PM Go/No-Go |
*(Nur die für den gewählten Pfad erforderlichen Ringe einschließen)*
---
## R3-Kohortenplan
**Zuerst:** Test-Mandanten – sichere Aktivierung vor Live-Mandanten bestätigen.
| Welle | % | Wer | Targeting | Go/No-Go-Gate |
|-------|---|-----|-----------|---------------|
| 0 | — | Test-Mandanten | Externe Test-Mandanten | Keine Vorfälle für 48 h |
| 1 | 5 % | Niedriger ARR | [Kriterien] | [Metrik] stabil für [Backzeit] |
| 2 | 15 % | Niedrig-mittlerer ARR | [Kriterien] | [Metrik] stabil für [Backzeit] |
| 3 | 35 % | Mittlerer ARR | [Kriterien] | [Metrik] stabil für [Backzeit] |
| 4 | 65 % | Mittlerer-hoher ARR | [Kriterien] | [Metrik] stabil für [Backzeit] – verlängert |
| 5 | 100 % | Alle Berechtigten | Filter entfernen | [Metrik] stabil für [Backzeit] |
---
## LaunchDarkly-Konfiguration
**1. Feature-Flag erstellen**
- Flag-Key: `[funktionsname]-rollout` (Kleinbuchstaben, Bindestriche)
- Typ: Boolean
- Standard (aus): false für alle Umgebungen
**2. Umgebungen konfigurieren**
- `internal-qa` → R0: für R&D-QA-Team aktivieren
- `dogfooding` → R1: für interne Mitarbeiter-Mandanten aktivieren *(nur High-Touch)*
- `early-access` → R2: für benannte Customer-One-Mandanten aktivieren *(nur High-Touch)*
- `production` → R3: Targeting-Regeln unten
**3. Produktions-Targeting-Regeln (R3-Wellen)**
Welle 0 – Test-Mandanten:
- Regel: `tenant_type = "test"` → true ausliefern
Welle 1 – 5 %:
- Regel: `tenant_type = "live" AND arr_tier = "low"` → true für 5 % Rollout ausliefern
Welle 2 → 5: Rollout-Prozentsatz erhöhen und den `arr_tier`-Filter pro Welle erweitern.
Den `arr_tier`-Filter in Welle 5 (100 %) vollständig entfernen.
Falls Serviceeinschränkungen gelten:
- `AND deployed_services CONTAINS "[dienstname]"` zu jeder Regel hinzufügen.
Falls Regionseinschränkungen gelten:
- `AND region IN ["[region]"]` zu frühen Wellen hinzufügen; für Welle 4–5 entfernen.
**4. Gates zwischen Wellen**
- Fehlerrate, Latenz (p99) und Support-Tickets für die Backzeit überwachen.
- Nur zur nächsten Welle erweitern, nachdem die Go/No-Go-Kriterien erfüllt sind.
- Zum Anhalten oder Zurücksetzen: das Produktions-Flag auf false setzen – alle Mandanten kehren sofort zurück.
**5. Einzelner Toggle**
- R&D muss einen Flag-Key über alle betroffenen Komponenten implementieren.
- Vor R3-Start mit R&D bestätigen, dass alle Komponenten dasselbe Flag lesen.
---
## Verantwortlichkeiten & Besitzer
- **R&D** – Implementiert das Flag, besitzt R0–R1, validiert Single-Toggle-Abdeckung
- **PM** – Besitzt Kundenexposition (R2–R4), unterschreibt jedes Wellen-Gate, aktualisiert Kohortenplan
- **Product Ops** – Prüft Plan auf Einhaltung der verbindlichen Richtlinien vor R3-Start
## Offene Fragen / Annahmen
- [Liste der angenommenen oder noch mit R&D / BI zu bestätigenden Fakten]
Beispiel
Siehe reference.md für ein durchgearbeitetes Beispiel (NFI, hohe Auswirkung, 3-Monats-GA-Ziel), das einen ausgefüllten Plan mit ausgefüllter Kohortentabelle und LaunchDarkly-Regeln zeigt.