Wikonia:Code-Review verbessern (Projekt)


| 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.
| Ticket | Kurzbeschreibung | Typ |
|---|---|---|
| phorge:T781 | Hauptticket Infrastruktur-Change | Epic |
| phorge:T782 | Beispiel | Doku |
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
- Erfassung aller aktiven Repositories, Diffs und Projektstrukturen
- Dokumentation der aktuellen Probleme und Limitierungen
- Bewertung möglicher Zielsysteme (z. B. Gerrit, GitLab, Gitea/Forgejo, GitHub Enterprise)
- Auswahl der bevorzugten Zielstrategie
Phase 2 – Konzeption & Proof-of-Concept Bearbeiten
- Aufbau eines Testsystems / Test-Repos
- Testmigration einzelner Repositories
- Definition des neuen Review- und Merge-Workflows
- Evaluierung der Tool-Kompatibilität
Phase 3 – Migration & Parallelbetrieb Bearbeiten
- Pilotmigration
- Anpassung von Infrastruktur und Developer-Workflows
- Schrittweise Migration aller Repositories
- Parallelbetrieb zur Sicherstellung der Datenintegrität
Phase 4 – Außerbetriebnahme Bearbeiten
- Deaktivierung von Differential und Diffusion
- Archivierung historischer Daten
- 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.