Betriebskonzept erstellen: Git-Repos, Deployment, Workflow und Zugriffe #13

New issue

Open

opened 2026-03-30 19:18:27 +00:00 by David · 0 comments

David commented

2026-03-30 19:18:27 +00:00

Collaborator

Beschreibung

Es fehlt ein Betriebskonzept für Bruno, das die folgenden Bereiche abdeckt:

1. Git-Repo-Anlage und Konfiguration

Token-basierte Authentifizierung: Aktuell ist nur GITLAB_TOKEN in .env.example vorgesehen. Konzept für sichere Token-Verwaltung pro Repo (ggf. unterschiedliche Tokens für unterschiedliche GitLab-Gruppen/Instanzen).
Tickettyp-Eingrenzung: Die repo_registry.yaml kennt aktuell keine Zuordnung von Tickettypen. Es soll definiert werden, welche Repos für welche Tickettypen (Bug, Feature, Datenfehler) zuständig sind — ggf. als neues Feld ticket_types pro Repo-Eintrag.
Repo-Onboarding-Prozess: Schritt-für-Schritt-Anleitung, wie ein neues Repo ins System aufgenommen wird (Token, Keywords, Limits, PROJEKTKONTEXT.md).

2. Deployment-Ablauf

Webhook vs. Self-Deploy: Entscheidung wie Bruno selbst deployed wird:
- Option A: Forgejo/GitLab Webhook → automatisches Deployment bei Push auf main
- Option B: Manuelles Deployment per Script/Docker
Docker-Setup: docker-compose.yml und Dockerfile.backend existieren bereits — Konzept für Production-Deployment (Ports, Volumes, Restart-Policy, Health-Checks).
Update-Strategie: Wie werden Updates eingespielt ohne laufende Pipelines zu unterbrechen?

3. Workflow hinterlegen

Ticket-Lebenszyklus: Klarer Workflow von Odoo-Ticket bis MR-Merge:

Odoo (Neu) → Polling → Scoring → [Autopilot|Klärfall|Abgelehnt]
→ Preparation → Claude Code → MR → Review → Merge/Close

Klärfall-Workflow: Wer bearbeitet Klärfälle? Eskalationspfad? SLAs?
Fehler-Workflow: Was passiert bei failed Tickets? Retry-Logik? Manuelle Eingriffe?
Tickettyp-spezifische Workflows: Unterschiedliche Abläufe für Bug vs. Feature vs. Datenfehler (z.B. Datenfehler braucht kein Code-Review sondern DB-Prüfung).

4. Zugriffe und URLs

Konsolen-Zugang: SSH-Zugang zum Server, Log-Zugriff, Debugging
URLs:
- Bruno Dashboard (Frontend Port 3000)
- Bruno API (Backend Port 8000)
- Odoo-Instanz
- GitLab/Forgejo-Instanz
- AppSignal (falls aktiviert)
Datenbank: SQLite-Pfad, Backup-Strategie, Zugriff für Debugging
Berechtigungen: Wer hat Zugriff auf was? Admin vs. Viewer-Rollen (Vorbereitung für spätere Auth)

Hintergrund

Bruno ist als Codebase bereits weit fortgeschritten (Backend mit Pipeline, Scoring, Claude Runner, GitLab-Service, Frontend-Dashboard), aber es fehlt ein Betriebskonzept für den produktiven Einsatz. Ohne dieses Konzept kann das System nicht sinnvoll ausgerollt und betrieben werden.

Akzeptanzkriterien

Dokument BETRIEBSKONZEPT.md im Repo-Root erstellt
Git-Repo-Onboarding beschrieben: Token-Setup, repo_registry.yaml Einträge, Tickettyp-Zuordnung
Deployment-Variante gewählt und dokumentiert (inkl. Docker-Konfiguration)
Vollständiger Ticket-Workflow als Beschreibung hinterlegt
Zugriffs-Matrix erstellt (wer/was/wo)
URL-Übersicht mit allen relevanten Endpunkten
Backup-Strategie für SQLite-Datenbank definiert
Update/Rollback-Prozess beschrieben

Technische Hinweise

Betroffene Dateien:
- Neu: BETRIEBSKONZEPT.md (Hauptdokument)
- repo_registry.yaml — ggf. Schema erweitern um ticket_types, auth_token_env
- backend/models/repo.py — ggf. neue Felder für Tickettyp-Zuordnung
- backend/config.py — ggf. neue Settings für Deployment
- docker-compose.yml — Production-Konfiguration ergänzen
- .env.example — neue Variablen dokumentieren
Ansatz: Zuerst Konzeptdokument erstellen, dann daraus Issues für die technische Umsetzung ableiten
Migration nötig: Noch nicht — erst nach Umsetzung der Schema-Änderungen

Aufwand: L

Mehrere Bereiche müssen durchdacht und dokumentiert werden. Daraus entstehen weitere Umsetzungs-Issues.

## Beschreibung Es fehlt ein Betriebskonzept für Bruno, das die folgenden Bereiche abdeckt: ### 1. Git-Repo-Anlage und Konfiguration - **Token-basierte Authentifizierung**: Aktuell ist nur `GITLAB_TOKEN` in `.env.example` vorgesehen. Konzept für sichere Token-Verwaltung pro Repo (ggf. unterschiedliche Tokens für unterschiedliche GitLab-Gruppen/Instanzen). - **Tickettyp-Eingrenzung**: Die `repo_registry.yaml` kennt aktuell keine Zuordnung von Tickettypen. Es soll definiert werden, welche Repos für welche Tickettypen (Bug, Feature, Datenfehler) zuständig sind — ggf. als neues Feld `ticket_types` pro Repo-Eintrag. - **Repo-Onboarding-Prozess**: Schritt-für-Schritt-Anleitung, wie ein neues Repo ins System aufgenommen wird (Token, Keywords, Limits, PROJEKTKONTEXT.md). ### 2. Deployment-Ablauf - **Webhook vs. Self-Deploy**: Entscheidung wie Bruno selbst deployed wird: - Option A: Forgejo/GitLab Webhook → automatisches Deployment bei Push auf `main` - Option B: Manuelles Deployment per Script/Docker - **Docker-Setup**: `docker-compose.yml` und `Dockerfile.backend` existieren bereits — Konzept für Production-Deployment (Ports, Volumes, Restart-Policy, Health-Checks). - **Update-Strategie**: Wie werden Updates eingespielt ohne laufende Pipelines zu unterbrechen? ### 3. Workflow hinterlegen - **Ticket-Lebenszyklus**: Klarer Workflow von Odoo-Ticket bis MR-Merge: ``` Odoo (Neu) → Polling → Scoring → [Autopilot|Klärfall|Abgelehnt] → Preparation → Claude Code → MR → Review → Merge/Close ``` - **Klärfall-Workflow**: Wer bearbeitet Klärfälle? Eskalationspfad? SLAs? - **Fehler-Workflow**: Was passiert bei `failed` Tickets? Retry-Logik? Manuelle Eingriffe? - **Tickettyp-spezifische Workflows**: Unterschiedliche Abläufe für Bug vs. Feature vs. Datenfehler (z.B. Datenfehler braucht kein Code-Review sondern DB-Prüfung). ### 4. Zugriffe und URLs - **Konsolen-Zugang**: SSH-Zugang zum Server, Log-Zugriff, Debugging - **URLs**: - Bruno Dashboard (Frontend Port 3000) - Bruno API (Backend Port 8000) - Odoo-Instanz - GitLab/Forgejo-Instanz - AppSignal (falls aktiviert) - **Datenbank**: SQLite-Pfad, Backup-Strategie, Zugriff für Debugging - **Berechtigungen**: Wer hat Zugriff auf was? Admin vs. Viewer-Rollen (Vorbereitung für spätere Auth) ## Hintergrund Bruno ist als Codebase bereits weit fortgeschritten (Backend mit Pipeline, Scoring, Claude Runner, GitLab-Service, Frontend-Dashboard), aber es fehlt ein Betriebskonzept für den produktiven Einsatz. Ohne dieses Konzept kann das System nicht sinnvoll ausgerollt und betrieben werden. ## Akzeptanzkriterien - [ ] Dokument `BETRIEBSKONZEPT.md` im Repo-Root erstellt - [ ] Git-Repo-Onboarding beschrieben: Token-Setup, `repo_registry.yaml` Einträge, Tickettyp-Zuordnung - [ ] Deployment-Variante gewählt und dokumentiert (inkl. Docker-Konfiguration) - [ ] Vollständiger Ticket-Workflow als Beschreibung hinterlegt - [ ] Zugriffs-Matrix erstellt (wer/was/wo) - [ ] URL-Übersicht mit allen relevanten Endpunkten - [ ] Backup-Strategie für SQLite-Datenbank definiert - [ ] Update/Rollback-Prozess beschrieben ## Technische Hinweise - Betroffene Dateien: - Neu: `BETRIEBSKONZEPT.md` (Hauptdokument) - `repo_registry.yaml` — ggf. Schema erweitern um `ticket_types`, `auth_token_env` - `backend/models/repo.py` — ggf. neue Felder für Tickettyp-Zuordnung - `backend/config.py` — ggf. neue Settings für Deployment - `docker-compose.yml` — Production-Konfiguration ergänzen - `.env.example` — neue Variablen dokumentieren - Ansatz: Zuerst Konzeptdokument erstellen, dann daraus Issues für die technische Umsetzung ableiten - Migration nötig: Noch nicht — erst nach Umsetzung der Schema-Änderungen ## Aufwand: L Mehrere Bereiche müssen durchdacht und dokumentiert werden. Daraus entstehen weitere Umsetzungs-Issues.