Release-Readiness als überprüfbare Evidenz statt als Bauchgefühl.
ReleaseProof wertet einen ausgewählten Jira-Release-Scope gegen sieben feste Regeln aus und liefert Score, Findings und eine Evidence-Matrix auf Issue-Ebene. Die Auswertung ist deterministisch und verwendet keine generative KI. Die Freigabeentscheidung bleibt beim Team.
| Issue | R1 | R2 | R3 | R4 | R5 | R6 | R7 |
|---|---|---|---|---|---|---|---|
| PROJ-412 | Akzeptanzkriterien vorhanden: erfüllt | Akzeptierter Workflow-Status: erfüllt | Keine offenen Subtasks: erfüllt | Keine blockierenden Links: erfüllt | Korrekte Release-Version: erfüllt | Kein Blocker-Label: erfüllt | Freigabemarker vorhanden: erfüllt |
| PROJ-418 | Akzeptanzkriterien vorhanden: erfüllt | Akzeptierter Workflow-Status: erfüllt | Keine offenen Subtasks: nicht erfüllt | Keine blockierenden Links: erfüllt | Korrekte Release-Version: erfüllt | Kein Blocker-Label: erfüllt | Freigabemarker vorhanden: nicht erfüllt |
| PROJ-421 | Akzeptanzkriterien vorhanden: nicht erfüllt | Akzeptierter Workflow-Status: erfüllt | Keine offenen Subtasks: erfüllt | Keine blockierenden Links: erfüllt | Korrekte Release-Version: nicht erfüllt | Kein Blocker-Label: erfüllt | Freigabemarker vorhanden: nicht erfüllt |
DEMO Synthetische Issue-Schlüssel. Keine realen Projektdaten.
Mechanismus
Wie es funktioniert
Der Ablauf von ReleaseProof in den Schritten, die im Produkt tatsächlich existieren. Der Schritt in Gold ist der, an dem ein Mensch entscheidet.
- 01
Scope konfigurieren
Textquelle und VERSION_ONLY oder JQL_SCOPE
setup
- 02
Issue-Population sammeln
Vollständige Erfassung, sonst Abbruch
read-only
- 03
Sieben Regeln auswerten
Deterministisch, ohne generative KI
deterministic
- 04
Evidence-Matrix
Regelergebnis je Issue
evidence
- 05
Go / No-Go
Die Entscheidung bleibt im Kundenprozess
gate
Funktionen
Was das Produkt konkret leistet
Sieben deterministische Regeln
Akzeptanzkriterien vorhanden, akzeptierter Workflow-Status, keine offenen Subtasks, keine blockierenden Links, korrekte Release-Version, kein Blocker-Label, Freigabemarker vorhanden.
Zwei Scope-Modi
VERSION_ONLY oder JQL_SCOPE. Im JQL-Modus bleibt ein Issue mit fehlender oder falscher fixVersion sichtbar und fällt durch die Versionsregel.
Evidence-Matrix auf Issue-Ebene
Jedes Issue trägt sein Regelergebnis. Der Bericht zeigt, warum ein Release rot ist – nicht nur dass er es ist.
Nur Leserechte
Die Forge-App fordert `read:jira-work` und `storage:app` an. Schreibrechte auf Jira werden nicht angefragt.
Veränderung
Vorher, mit SBS, nachher
Vorher
- Release-Readiness wird in einer Besprechung geschätzt.
- Fehlende Akzeptanzkriterien fallen erst nach dem Deployment auf.
- Der Nachweis für die Freigabeentscheidung existiert nur als Protokollnotiz.
ReleaseProof
Nachher
- Sieben feste Regeln laufen deterministisch gegen den definierten Scope.
- Jedes Issue trägt sein Regelergebnis in der Evidence-Matrix.
- Der Bericht zeigt, was korrigiert werden muss – die Entscheidung bleibt beim Team.
Für wen es gebaut ist
- Engineering- und Release-Verantwortliche
- Quality Engineering
- Regulierte oder kontrollierte Softwareteams
Umgebung und Anbindung
- Atlassian Forge
- Jira Cloud (nur lesend)
Aufgeführt sind ausschließlich Anbindungen, die im Produkt umgesetzt sind. Weitere Schnittstellen klären wir vor einem Pilot statt sie hier zu behaupten.
Governance
Grenzen und Nachweise
Was das Produkt sicherstellt — und was es ausdrücklich nicht entscheidet.
- Die Analyse ist deterministisch und verwendet keine generative KI.
- Unerwartete Jira-Strukturen, unvollständige Paginierung oder unsichere Mappings brechen die Analyse ab, statt ein Teilergebnis auszuweisen.
- Öffentliche Ergebnisansichten enthalten keine vollständigen Beschreibungs- und Akzeptanzkriterientexte.
- ReleaseProof unterstützt eine Entscheidung – es gibt keinen Release frei und bestätigt keine Konformität.
Nächster Schritt
ReleaseProof im eigenen Kontext prüfen
Wir zeigen den Ablauf an Ihren Unterlagen — oder an synthetischen Beispieldaten, wenn das für einen ersten Termin passender ist.