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 | Quelltext 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 | Quelltext 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 | Quelltext 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 | Quelltext 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 | Quelltext bearbeiten]
Phase 1 – IST-Analyse & Strategie[Bearbeiten | Quelltext 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 | Quelltext 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 | Quelltext bearbeiten]
- Pilotmigration
- Anpassung von Infrastruktur und Developer-Workflows
- Schrittweise Migration aller Repositories
- Parallelbetrieb zur Sicherstellung der Datenintegrität
Phase 4 – Außerbetriebnahme[Bearbeiten | Quelltext bearbeiten]
- Deaktivierung von Differential und Diffusion
- Archivierung historischer Daten
- Finaler Umstieg auf das neue Review-System
5. Kandidatensysteme (Initial-Analyse)[Bearbeiten | Quelltext 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 | Quelltext 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 | Quelltext bearbeiten]
Das Projekt wird phasenbasiert dokumentiert und versioniert.
Zu jedem Schritt entstehen Untertickets, die in Phorge verwaltet und hier im Wiki verlinkt werden.