Zum Hauptinhalt springen

CI/CD-Flow

Der vollständige Weg eines Features von Issue-Erstellung bis Production.

Phase 1: Issue → PR​

  1. Issue erstellen (Mensch) — via Issue-Template mit Akzeptanzkriterien
  2. WF-11 Impact Analysis (n8n) — analysiert Komplexität, erstellt Test-Cases in Kiwi
  3. Copilot zuweisen (n8n/Mensch) — Issue an copilot-swe-agent[bot]
  4. Code + PR (Copilot) — Feature-Branch feat/<description>, PR gegen develop

Phase 2: CI​

  1. ci.yml (GitHub Actions) — Build, Lint, Unit Tests, Structural Gate
  2. workflow_run Webhook → n8n empfängt CI-Ergebnis

Phase 3: Merge & Deploy​

  1. WF-01 CI-Result-Handler (n8n) — prüft CI-Status, merged PR (squash)
  2. WF-05 Board-Move (n8n) — Issue nach "Review / Staging"
  3. staging.yml (GitHub Actions) — Deploy auf Staging-VPS

Phase 4: E2E & Abnahme​

  1. staging-test.yml (GitHub Actions) — Playwright E2E-Tests
  2. WF-02 Staging-Result-Handler (n8n) — E2E-Ergebnis auswerten
  3. Board-Move → "Abnahme"
  4. Menschliche Abnahme → Done

Wichtige Regeln​

  • Merge erfolgt immer über n8n (PAT-basiert), nie über GitHub UI
  • GitHub Projects Board-Automationen sind deaktiviert — n8n steuert alle Moves
  • workflow_run Events werden über Webhooks an n8n gesendet