6-Stationen-Workflow Design → Operate mit AI-Gates an drei Punkten
Design, Code, CI, QAS, Deploy, Operate – sechs Stationen, drei davon mit AI-Gate. Was an jeder Station passiert, was die AI prüft, und welche Quality-Gates den Wechsel zwischen Stationen blockieren.
Der Workflow im Überblick
```mermaid
flowchart LR
IN[Business Need]
IN --> S1[1 · DESIGN
PO + Architect]
S1 --> S2[2 · CODE
Dev + Claude]
S2 -->|PR ready| S3[3 · CI / GATES
Pipeline + AI-Reviewer]
S3 -->|Green| S4[4 · QAS + REPRO
Tester + AI Privacy Lead]
S4 -->|UAT-OK| S5[5 · DEPLOY
Operator + 4-Augen]
S5 -->|Live| S6[6 · OPERATE
SRE + Audit]
style S3 fill:#fed7aa,stroke:#c2410c style S4 fill:#fed7aa,stroke:#c2410c style S5 fill:#fed7aa,stroke:#c2410c ```
Drei Stationen sind AI-Gates (S3, S4, S5). Hier ist der „AI Privacy & Operations Lead“ Gatekeeper bzw. spielt eine Rolle.
Station 1 – Design
Wer: Product Owner + Architect
Tools: ADRs (Architecture Decision Records), CDS-Schema-Drafts, Prompt-Designs für AI-Komponenten
Output: Design-Dokument als Markdown-Datei im Repo
Quality-Gate: kein automatisches, nur Architect-Review
Wichtige AI-Berührung: wenn der Output ein AI-Component-Design ist, wird der System-Prompt entworfen und das Eval-Set definiert.
Station 2 – Code
Wer: Developer + Claude Code als Pair-Programmer
Tools: Dev VDI Pool, cds watch, VS Code, @anthropic-ai/cli
Inputs: Ticket, ADR, CDS-Draft, reproduzierbarer Bug
Outputs: Working Code, Unit-Tests, CDS-Schema-Update, PR
Wichtige Disziplin: kein PRD-Daten loaded werden in Dev VDI. Synthetic Fixtures (~50 Rows) reichen für Unit-Tests.
Station 3 – CI/Gates (AI-Gate #1)
Wer: Automatisierte Pipeline + Claude als AI-Reviewer
Tools: GitHub Actions, ESLint, cds build, Jest, CodeQL, Snyk
Sequenz:
1. PUSH → PR opens
2. LINT (Style)
3. BUILD (cds build)
4. TEST (Coverage ≥ 80%)
5. SAST (CodeQL, Snyk)
6. AI-REVIEW (Claude prüft Spec-Adherence + Security-Smell + CAP-Idiom)
7. MERGE
Quality-Gate: alle 6 Stages müssen grün. Bei Fehlern: Block-Merge, Loop zurück zu Station 2.
AI-Spezifisches: Claude reviewt kommentierend, nicht blockierend. Ein Mensch entscheidet bei [changes-requested].
Station 4 – QAS + Repro (AI-Gate #2)
Wer: Tester + AI Privacy & Ops Lead (bei Eskalationen)
Tools: Hardened AI VDI Pool, anonymisiertes QAS, Claude in der VDI
Workflow: 1. Ticket triagiert (Severity, Scope) 2. Repro auf QAS mit anonymisierten Daten 3. Wenn nötig: AI-assisted Analyse in Hardened AI VDI (Session aufgezeichnet) 4. Fix als PR (zurück zu Station 3)
Was nie ins AI-Gate kommt: rohe PRD-Rows, Customer-Names im Klartext, Salt/HSM-Material.
Station 5 – Deploy (AI-Gate #3)
Wer: Operator + 4-Augen-Approval (AI Privacy & Ops Lead + zweiter Approver)
Targets:
Target A – SAP BTP (für CAP-Module + BTP-hosted Agents)
- Build:
npx cds build --production+ MTA-Archive - Approve: 4-Augen
- Deploy:
cf deploy/mta deploy→ DEV → QAS → PRD - Verify: Smoke-Tests via Approuter, KPI-Snapshot
- Operate: BTP Cockpit, Audit Log Service, Alert Notification
Target B – Microsoft Azure (für Azure-hosted Agents)
- Build: Container-Image, push zu Azure Container Registry
- Approve: 4-Augen via Azure DevOps
- Deploy: Container Apps / Functions, Bicep / Terraform
- Verify: Health-Probes, Prompt-Evals, Canary
- Operate: Azure Monitor, App Insights
Gemeinsamkeiten: Same Approver, Same Audit-Log-Destination, Same Incident-Process.
Station 6 – Operate
Wer: SRE-Team + Audit (DPO/Compliance)
Tools: BTP Cockpit, Azure Monitor, Audit-Log-Dashboards
Routinen: - Daily: KPI-Check (Pipeline-Health, Token-Usage, Error-Rate) - Weekly: Audit-Log-Review-Sample - Monthly: Cost-Report, Operations-Reflection - Quarterly: External-Audit-Prep, Tabletop-Exercise
Kontinuierlich: Tickets, die Bug-Klassen erkennen lassen, gehen zurück an Station 1 (Design für strukturelle Verbesserung).
Was zwischen den Stationen blockiert
Quality-Gates sind nicht weich – sie blockieren Fortschritt:
| Gate | Blockiert wenn |
|---|---|
| Design → Code | ADR fehlt oder unvollständig |
| Code → CI | PR nicht aufgemacht oder ohne Beschreibung |
| CI → QAS | Eines der 6 Pipeline-Stages rot |
| QAS → Deploy | UAT-Signoff fehlt oder Bug-Repro nicht abgeschlossen |
| Deploy → Operate | 4-Augen-Approval nicht dokumentiert |
| Operate → Re-Plan | (kein Block – kontinuierlich) |
Statistik aus 18 Monaten BAMVP
- Mittlere Zeit pro Ticket durch alle 6 Stationen: 5-12 Tage (ohne Bug-Repro-Eskalation), 8-18 Tage mit
- AI-Reviewer-Approval-Rate auf Anhieb: ~78% (22% brauchen mind. einen Loop zurück)
- Repro-First-Erfolgs-Rate: 88-92% (siehe usecase.bamvp.repro-first-anonymized-qas-2026)
- Deploy-Frequenz: 3-5 pro Woche im Durchschnitt
- Incident-Rate: 0 Sev-1, 4-6 Sev-2 pro Quartal
Was an dem Workflow überraschend wichtig ist
- Disziplin der Quality-Gates: nie aufweichen, auch nicht für „dringende“ Tickets. Das ist der Wert des Setups.
- Audit-Spur durch alle 6 Stationen: jede Aktion ist nachvollziehbar von Design bis Operate.
- Single Approver-Rolle für die AI-Gates: AI Privacy & Ops Lead an S3/S4/S5 – eine Person, ein Stempel, eine Spur.
Wer den Workflow einrichten will
Ein Workshop (halbtägig) baut Ihren 6-Stationen-Workflow für Ihre Domäne, mit konkreten Quality-Gates und Tool-Setup. Output: Workflow-Diagramm + lauffähiger CI-Skeleton + Eskalations-Runbook.
Stand: 2026-05-10
