Zusammenfassung
Dieser Task dient der Definition und Dokumentation des SOLL-Zustands für unser zukünftiges Code-Review- und Repository-Hosting-System nach der Migration. Die Definition erfolgt auf Basis der vorherigen IST-Analyse und bildet die entscheidende Grundlage für die technische Implementierung und den Change-Management-Prozess.
Das Ergebnis ist ein finales SOLL-Konzept-Dokument, das alle funktionalen und infrastrukturellen Anforderungen an das neue System festlegt.
Ziele der SOLL-Konzeption
Die Konzeption muss die folgenden Bereiche adressieren und definieren:
1. Zielsystem und Architektur
- Plattform-Entscheidung: Benennung der final ausgewählten Zielplattform (z.B. GitLab, GitHub Enterprise, o.ä.).
- Architektur-Design:
- Detailplan der neuen Infrastruktur (Server, Datenbanken, Speicherung) zur Gewährleistung von Stabilität und Skalierbarkeit.
- Integrationsschema des Zielsystems in unsere bestehenden Systeme (CI/CD, Authentifizierung, Monitoring).
- Definition der Hochverfügbarkeits- (HA) und Disaster Recovery-Strategie (DR).
- Datenmigrationsstrategie:
- Festlegung der Methode zur Überführung historischer Daten (Repository-Verlauf, Reviews, Kommentare, Tickets).
2. End-to-End Workflow (Ziel-Prozess)
- Workflow-Definition: Detaillierte Beschreibung des neuen, Pull/Merge-Request-basierten Entwicklungs-Workflows.
- Prozess-Visualisierung: Erstellung eines Flussdiagramms (Mermaid/Pholio) des neuen End-to-End-Prozesses – vom Feature-Branch bis zum Merge.
- Automatisierungsregeln (Ersatz für Herald):
- Definition der Automatisierungen, die die Funktionalität der kritischen Phorge Herald Rules im Zielsystem ersetzen (z.B. automatisches Reviewer-Routing, CI-Checks, Status-Updates).
- Qualitätssicherung:
- Definition von Code-Qualitäts-Gates und notwendigen statischen Analyse-Tools, die in den Merge-Request-Prozess integriert werden.
3. Organisation und Rollen (Zielzustand)
- Rollenkonzept: Abbildung der bisherigen Phorge-Rollen auf die Rollen des neuen Systems (z.B. Differential Reviewer zu Code Owner oder Maintainer).
- Berechtigungskonzept: Definition der Zugriffsrechte und des Namespace-Managements im Zielsystem (z.B. wie werden sensible Repositories geschützt?).
- Schulungskonzept: Entwurf eines Plans für die Schulung der Entwicklerteams und Administratoren auf den neuen Workflow und die neue Plattform.
Nächste Schritte
- Zielsystem-Auswahl: Vorstellung der finalen Empfehlung für die Zielplattform.
- Architektur-Review: Abnahme des SOLL-Architektur-Designs durch die Infrastruktur-Leitung.
- Dokumentation: Erstellung des offiziellen SOLL-Konzept-Dokuments.