Zum Hauptinhalt springen

Checkliste vor der Migration

Arbeite vor der Migration diese Checkliste für deinen bestehenden Mandanten durch, um die Umstände aufzudecken, die mitten in einer Migration für Überraschungen sorgen: übergroße Repositorys, große LFS-Bestände, komplexe CI-Pipelines und Integrationen von Drittanbietern, die sich nicht automatisch wieder verbinden.

Das Skript verwenden (empfohlen)

Du kannst die Checkliste unten von Hand abarbeiten, aber fremforge liefert eine Shell-basierte Bewertung mit, die jede Prüfung auf dieser Seite automatisiert. Sie blättert durch die Listen der Repositorys, Mitglieder und Webhooks beim Quellanbieter und erzeugt einen einzigen Markdown-Bericht, den du an das Migrationsticket anhängen kannst:

# Clone the migration tools (read-only — no fremforge account needed yet)
curl -sSL https://docs.frem.sh/tools/pre-migration-check.sh -o pre-migration-check.sh
chmod +x pre-migration-check.sh

# GitHub
GITHUB_TOKEN=<your-PAT> ./pre-migration-check.sh github <your-org> > report.md

# GitLab
GITLAB_TOKEN=<your-PAT> ./pre-migration-check.sh gitlab <your-group> > report.md

# Azure DevOps
ADO_TOKEN=<your-PAT> ./pre-migration-check.sh azure-devops <your-org> > report.md

Das Skript liest nur: Es setzt ausschließlich GET-Aufrufe gegen die API des Quellanbieters ab und verändert nichts in deinem Mandanten. Der Bericht deckt dasselbe ab wie die manuelle Checkliste unten, dazu Repository-Listen, die das Blättern berücksichtigen (Sicherheitsgrenze bei 5000 Repositorys), und einen Abgleich der Marketplace-Actions mit der Kompatibilitätsmatrix. Das Scannen der Historie nach Secrets liegt vor der Migration in deiner Verantwortung: Führe gitleaks detect lokal für jedes Repository aus, bei dem du Bedenken hast. Der gitleaks-Pre-Receive-Hook von fremforge blockiert Pushes, die erkannte Secrets enthalten; löst ein Commit aus der Historie ihn aus, folge dem Runbook für Secrets in der Historie. Schick die Ausgabe des Skripts an support@frem.sh, wenn du sie vor dem Migrationstag mit jemandem aus dem fremforge-Team durchgehen möchtest.

Wenn du für das Migrationsticket eine maschinenlesbare Ausgabe brauchst, gib --json vor dem Plattformargument an:

GITHUB_TOKEN=<your-PAT> ./pre-migration-check.sh --json github <your-org> > report.json

Die JSON-Hülle entspricht dem Markdown-Bericht (Größe, LFS und Anzahl der Webhooks pro Repository, Abgleich mit dem Marketplace, Liste der Blocker und Warnungen), sodass du Läufe vor und nach der Migration vergleichen oder sie an ein Ticket anhängen kannst.

Checkliste vor der Migration

Prüfe vor der Migration:

  • Anzahl und Gesamtgröße der Repositorys (mit git count-objects -vH in jedem Repository)
  • LFS-Objekte: Führe git lfs ls-files aus, um per LFS verwaltete Dateien und ihre Größen zu ermitteln
  • CI-Workflow-Dateien: Prüfe .github/workflows/ oder .gitlab-ci.yml auf Syntax und auf Action-Referenzen, die für fremforge angepasst werden müssen
  • Regeln für den Branch-Schutz: Notiere erforderliche Statuschecks, erforderliche Reviewer und Einschränkungen für Force-Pushes, um sie in fremforge neu anzulegen
  • Secrets und Umgebungsvariablen: Liste alle Secrets auf Repository- und Organisationsebene auf, um sie nach der Migration neu einzutragen
  • Eigener Git-Hostname (z. B. git.acme.com): Verweisen deine bestehenden Werkzeuge, CI-Konfigurationen, Build-Skripte oder Onboarding-Dokumente für Entwickler auf einen eigenen Git-Hostnamen statt auf die kanonische Domain der Quellplattform? Falls ja, lies vor der Migration GitHub-Migration § Vanity-CNAMEs: fremforge stellt derzeit keine TLS-Zertifikate für per CNAME eingebundene Kundendomains aus, und der Migrationstag ist nicht der richtige Moment, das herauszufinden.

Was geprüft wird

Alle Plattformen:

  • Anzahl und Größe der Repositorys. Alles über 500 MB erhält eine Warnung (der Import ist langsamer); alles über 2 GB erhält eine Blocker-Markierung (der Weg über einen Mirror-Klon ist nötig).
  • Größe des LFS-Bestands bei Repositorys, die LFS deklarieren.
  • Anzahl der Webhooks pro Repository: Ab 3 Webhooks gibt es eine Warnung, damit du jeden für die Wiederverbindung dokumentierst.

Speziell für GitHub:

  • Anzahl der unterschiedlichen Marketplace-Actions über alle Workflows. Ab 10 unterschiedlichen Actions wirst du aufgefordert, sie mit der Kompatibilitätsmatrix für den Marketplace abzugleichen.
  • Geschützte Branches: werden dokumentiert, damit du sie in fremforge neu anlegen kannst.
  • Actions-Secrets, Variablen und Container-Pakete auf Organisationsebene: Sie alle müssen neu eingetragen oder separat migriert werden.

Speziell für GitLab:

  • Heuristik für die Komplexität von .gitlab-ci.yml (Stages, include:-Referenzen, extends:-Ketten, services:-Sidecars). Komplexe Pipelines erhalten eine Warnung zum Zeitbudget.
  • Deployments von GitLab Pages werden für die manuelle Neukonfiguration markiert.
  • Anzahl der CI/CD-Variablen auf Gruppenebene.

Speziell für Azure DevOps:

  • Anzahl der klassischen Pipelines (nicht YAML), als Blocker markiert. Stelle sie vor der Migration in ADO auf YAML um.
  • Anzahl der Pipelines: Ein großes Pipeline-Volumen wird als Warnung zum Zeitbudget markiert.
  • Anzahl der Service Connections, markiert für den Ersatz durch OIDC-Föderation.
  • Anzahl der Variablengruppen.
  • Anzahl der Testpläne, als Blocker markiert, weil fremforge keine direkte Entsprechung hat.

Umfang dieser Checkliste

Diese Checkliste prüft die Migrationsbereitschaft, nicht Codequalität und keine Sicherheitsaudits. Sie tut Folgendes nicht:

  • Codequalität, Testabdeckung oder Erfolgsquoten der CI bewerten.
  • Secrets auf Sensibilität oder Offenlegung prüfen (nutze dafür nach der Migration das Secret-Scanning von fremforge vor dem Empfang).
  • Prüfen, ob Workflows korrekt geschrieben sind, nur ob sie auf eine handhabbare Zahl externer Actions verweisen.
  • Beurteilen, ob der Funktionsumfang von fremforge zum Workflow deines Teams passt. Das ist ein Thema für ein Vertriebsgespräch, kein Punkt auf einer Checkliste.

Für betriebliche Details über die Checkliste hinaus beschreiben der Leitfaden zur GitHub-Migration, der Leitfaden zur GitLab-Migration und der Leitfaden zur Azure-DevOps-Migration die Importverfahren Schritt für Schritt.

Hilfe

Wenn du unerwartete Ergebnisse hast und Hilfe bei der Einordnung brauchst, schreib an support@frem.sh. Kunden aus der Early-Adopter-Phase haben für die Migration direkten Zugang zum Entwicklungsteam von fremforge.

Siehe auch: Leitfaden zur GitHub-Migration · Leitfaden zur GitLab-Migration · Leitfaden zur Azure-DevOps-Migration · Kompatibilitätsmatrix der 20 wichtigsten Marketplace-Actions.

Secrets in der Historie