Wikonia:Code-Review verbessern (Projekt)

Projektstatus „Code-Review verbessern“
top
top
Status: vorbereitung
Start: 23.11.2025
Info: Intrastruktur-Änderung an den bereits etablierten Wikonia:Work-Tools (Projekt).

1. Projektbeschreibung Bearbeiten

Das Projekt „Code-Review verbessern“ hat das Ziel, das bestehende Review- und Repository-System von Wikonia grundlegend zu modernisieren. Die derzeitige Kombination aus Phorge Differential, Diffusion und Arcanist verursacht regelmäßig technische, organisatorische und workflow-bezogene Probleme. Um die langfristige Stabilität der Wikonia-Entwicklung sicherzustellen, wird eine Ablösung dieser Module geprüft und ein moderner, zukunftsfähiger Review-Workflow vorbereitet.

Die Dokumentation des Projekts und alle zugehörigen Entscheidungen finden offen und transparent hier im Wiki statt.

Dokumentation Bearbeiten

Das Projekt wird öffentlich hier im Ticket und den folgenden Unterseiten dokumentiert, das Tracking der Aufgaben erfolgt in Phorge.

Phorge-Tickets
Ticket Kurzbeschreibung Typ
phorge:T781 Hauptticket Infrastruktur-Change Epic
phorge:T782 Beispiel Doku
Hinweis
Dieses Projekt wird parallel mit unserem Kollaborations-Tool Phorge verfolgt. Die Tickets dienen der einzeldokumentation und der Nachverfplgung des Projektstands.
Hilfe zu Phorge findest du unter Hilfe:Phorge


2. Ausgangslage (IST-Zustand) Bearbeiten

Die derzeit genutzten Komponenten:

  • Phorge Differential (Code-Review)
  • Phorge Diffusion (Repository-Hosting)
  • Arcanist CLI (Lokales Werkzeug für Diffs & Landings)

weisen mehrere strukturelle Schwächen auf:

  • Veraltete oder eingeschränkt gepflegte Code-Basis
  • Unzuverlässiger Workflow bei Diffs & Landings
  • Hohe Abhängigkeit von lokalem Arcanist-State
  • Fehlende moderne CI/CD-Integration
  • Kein serverseitiges Patchset-Management
  • Keine Code-Ownership-Mechanismen
  • Technische Instabilitäten im Zusammenspiel von Git ↔ Arcanist ↔ Phorge

Diese Situation stellt ein technisches Risiko für künftige Entwicklung und Skalierung dar.

3. Zielsetzung (SOLL-Zustand) Bearbeiten

Das Projekt verfolgt die Einführung eines modernen, stabilen und zukunftssicheren Code-Review-Systems, das folgende Anforderungen erfüllt:

  • Ablösung von Differential, Diffusion und Arcanist
  • Einführung eines Pull-/Merge-Request-basierten Workflows
  • Vollständige Migration aller Repositories und relevanten Metadaten
  • Bessere Integration mit modernen CI/CD-Pipelines
  • Möglichkeit zu Code-Ownership, Review-Gates und Schutzmechanismen
  • Vereinfachte Bedienung, weniger Fehleranfälligkeit
  • Stabiler Betrieb auf eigener Infrastruktur

4. Projektphasen Bearbeiten

Phase 1 – IST-Analyse & Strategie Bearbeiten

  1. Erfassung aller aktiven Repositories, Diffs und Projektstrukturen
  2. Dokumentation der aktuellen Probleme und Limitierungen
  3. Bewertung möglicher Zielsysteme (z. B. Gerrit, GitLab, Gitea/Forgejo, GitHub Enterprise)
  4. Auswahl der bevorzugten Zielstrategie

Phase 2 – Konzeption & Proof-of-Concept Bearbeiten

  1. Aufbau eines Testsystems / Test-Repos
  2. Testmigration einzelner Repositories
  3. Definition des neuen Review- und Merge-Workflows
  4. Evaluierung der Tool-Kompatibilität

Phase 3 – Migration & Parallelbetrieb Bearbeiten

  1. Pilotmigration
  2. Anpassung von Infrastruktur und Developer-Workflows
  3. Schrittweise Migration aller Repositories
  4. Parallelbetrieb zur Sicherstellung der Datenintegrität

Phase 4 – Außerbetriebnahme Bearbeiten

  1. Deaktivierung von Differential und Diffusion
  2. Archivierung historischer Daten
  3. Finaler Umstieg auf das neue Review-System

5. Kandidatensysteme (Initial-Analyse) Bearbeiten

System Modell Vorteil Herausforderung
Gerrit Patchset-basiert Sehr stark bei Ownership, Review-Regeln, Skalierbarkeit Workflow-Umstellung erforderlich
GitLab (Self-Managed) Merge Requests CI/CD tief integriert, moderne UI Höherer Infrastrukturbedarf
Forgejo/Gitea Pull Requests Leichtgewichtig, self-hosted, modern Weniger Features im Enterprise-Bereich
GitHub Enterprise Pull Requests Sehr ausgereift, breite Integration Lizenzmodell / Kosten

6. Risiken & Herausforderungen Bearbeiten

  • Datenmigration: Verlust historischer Review-Daten (Mitigation: POC, Backups)
  • Übergangsphase: Paralleler Betrieb von Alt- und Neusystem
  • Umgewöhnung: Anpassung an neue Workflows
  • Komplexität: Systemischer Umbau der Infrastruktur

7. Projektorganisation Bearbeiten

Das Projekt wird phasenbasiert dokumentiert und versioniert.

Zu jedem Schritt entstehen Untertickets, die in Phorge verwaltet und hier im Wiki verlinkt werden.