Wikonia:Code-Review verbessern (Projekt)/Ist-Analyse

Mit dem Ticket phorge:T782 wurde eine weitergehende Analyse des kompletten Ist-Zustands mit Fokus auf die Architektur der Software angestrebt. Diese Analyse wird hier dokumentiert.

IST-Analyse: Systemlandschaft & aktueller Workflow

Phorge-System-Aufbau

• Maniphest: Tickets, Quests, Anforderungen (zentraler Dreh- und Angelpunkt)
• Herald: Automatische Ticketkommentare bei Commits
• Differential: Code-Review-System (technisch unzuverlässig, soll ersetzt werden)
• Diffusion: Git-Hosting innerhalb von Phorge (kein externer Git-Server)
  • Repositories liegen physisch im Dateisystem des Phorge-Backends
  • Anlage eines Repos erfordert Systemzugriff (Ordner anlegen, chmod/chown setzen)
  • Kein Self-Service, kein moderner Rechte- oder Branch-Schutz
• Audit: vorhanden, aber ungeeignet als verpflichtender Review-Mechanismus

	Git-Repositories Haupt-Repositories liegen innerhalb des Phorge-Dateisystems Hosting erfolgt über den internen Phorge-Git-Dienst GitHub dient als passiver Mirror (read-only) Feature-Branches werden nicht remote genutzt (instabil mit Arcanist)
	Arcanist (lokales CLI-Werkzeug) Bindeglied zwischen Git ↔ Differential Erzeugt Diffs und Patchsets (arc diff) Führt Landings aus (arc land), häufig fehleranfällig Kritischer Punkt: Arcanist speichert lokalen State, der leicht inkonsistent wird
	Entwicklerumgebung Lokaler Git-Workflow, Branch-Erstellung nur lokal Lokale IDE Feature-Branches werden lokal gehalten (nicht remote)

End-to-End-Workflow (IST)

1. Ticket wird in Maniphest erstellt
2. Entwickler legt lokalen Branch an: git checkout -b fix/T123
3. Änderungen und Commits werden lokal durchgeführt
4. arc diff erstellt Patchset in Differential
5. Reviewer kommentieren im Differential (nicht erzwingbar)
6. Merge/Landing erfolgt per arc land oder manuell bei Fehlern
7. Ticket in Maniphest wird automatisch oder manuell aktualisiert

Wichtige IST-Fakten

• Tickets müssen zwingend in Phorge bleiben
• Review und Git-Hosting sind derzeit fest miteinander gekoppelt
• Der aktuelle Review-Workflow ist fehleranfällig (Arcanist/Differential)
• Feature-Branches existieren nur lokal
• GitHub ist lediglich ein passiver Mirror
• Ziel-Workflow (Ticket → Branch → Review → Merge) bleibt grundsätzlich bestehen
• Git-Hosting ist verhandelbar
• Review-System ist explizit zur Ablösung vorgesehen