Die Migration von CI/CD-Pipelines ist eine häufige Aufgabe für DevOps-Ingenieure, insbesondere da Teams zunehmend auf einheitlichere und modernere Bereitstellungsplattformen umsteigen. In dieser Fallstudie aus der Praxis zeigen wir Ihnen Schritt für Schritt, wie mehrere Bitbucket-Repositorys und -Pipelines zu GitHub migriert werden, während gleichzeitig die CI-Workflows mithilfe von GitHub Actions modernisiert werden.
Die betroffenen Repositorys waren für Firmware-Builds verantwortlich, die auf OpenWRT und Yocto, zwei weit verbreitete Linux-basierte Frameworks für eingebettete Systeme. Das Ziel bestand nicht nur in der Migration des Quellcodes, sondern auch in der Konsolidierung fragmentierter Pipeline-Implementierungen zu einer einzigen, einheitlichen CI/CD-Architektur.
Dieser Artikel ist Teil 1 einer Reihe zum Thema Migration, in der es um die Migration von Repositorys und die Beibehaltung der Git-Historie, -Struktur und -Abhängigkeiten geht.
Migrationskontext und Herausforderungen
Die von dieser Migration betroffenen Repositorys verfügten über unterschiedliche CI-Implementierungen:
- Einige nutzten Bitbucket Pipelines und setzten dabei auf YAML-definierte Workflows
- Andere führten Bash-Skripte über Jenkins-Jobs aus
Eine der größten Herausforderungen bestand darin, diese Ansätze unter einer einzigen CI/CD-Plattform zu vereinen. Die vollständige Migration zu GitHub und die Vereinheitlichung auf GitHub Actions schufen eine übersichtliche und wartungsfreundliche Grundlage für die zukünftige Entwicklung.
Überblick über die Migrationsstrategie
Der Migrationsprozess umfasste drei Hauptziele:
- Repositorys von Bitbucket Cloud zu GitHub Cloud verschieben
- Behalte den vollständigen Git-Verlauf bei, einschließlich Zweigen, Tags und Referenzen
- Stellen Sie sicher, dass Submodule und Abhängigkeiten weiterhin ordnungsgemäß funktionieren
Da es sich um eine Bitbucket-Cloud-Umgebung handelte, kamen nicht alle Migrationswerkzeuge in Frage. Man entschied sich für einen direkten Git-basierten Ansatz, um während des gesamten Prozesses volle Kontrolle und Transparenz zu gewährleisten.
Schritt für Schritt: Migration von Repositorys von Bitbucket Cloud zu GitHub Cloud
Schritt 1: Erstelle ein neues Repository auf GitHub
Für jedes Projekt wurde auf GitHub ein leeres Repository angelegt, das denselben Namen trug wie das ursprüngliche Bitbucket-Repository. Dieses Repository diente als Ziel für die Migration.

Schritt 2: Klonen Sie das Bitbucket-Repository mit
Um den vollständigen Zustand des Repositorys einschließlich aller Branches und Tags zu erhalten, wurde ein gespiegelter Klon erstellt:
git clone --mirror git@bitbucket.org:workspace/project-repo.git
This creates a bare repository containing all Git objects and references, without checking out a working directory. A typical structure looks like:
branches config description HEAD hooks info objects packed-refs refs
Dies bestätigt, dass der gesamte Git-Verlauf lokal verfügbar ist.
Schritt 3: Das gespiegelte Repository auf GitHub hochladen
Anschließend wurde das gespiegelte Repository auf GitHub hochgeladen:
cd project-repo.git
git push --mirror git@github.com:workspace/project-repo.git
Dadurch wird sichergestellt, dass alle Branches, Tags und Referenzen genau so übertragen werden, wie sie in Bitbucket Cloud vorhanden waren.
Schritt 4: Führen Sie nach der Migration Plausibilitätsprüfungen durch
Nachdem das Repository gepusht worden war, wurden mehrere Überprüfungen durchgeführt:
- Stellen Sie sicher, dass alle Zweige korrekt migriert wurden
- Überprüfen Sie, ob die Tags und der Commit-Verlauf intakt sind
- Stellen Sie sicher, dass der richtige Standardzweig festgelegt ist
Bei Bedarf kann der Standard-Branch in GitHub wie folgt aktualisiert werden:
Repository → Einstellungen → Allgemein → Standardzweig

Diese Überprüfungen stellen sicher, dass das Repository für die Migration der CI/CD-Pipeline bereit ist.
Schritt 5: Aktualisieren der Git-Submodule nach der Migration
Viele der migrierten Repositorys nutzten Git-Submodule. Nach der Migration mussten alle Submodul-URLs aktualisiert werden, damit sie nun auf GitHub statt auf Bitbucket verweisen.
Vor der Migration:
[submodule "submodule_name"]
path = submodule_path
url = git@bitbucket.org:workspace/dependant-repo.git
Nach der Migration:
[submodule "submodule_name"]
path = submodule_path
url = git@github.com:workspace/dependant-repo.git
Nach der Aktualisierung die Submodule initialisieren und aktualisieren:
git submodule update --init --recursive
Synchronisierung verschachtelter Untermodule
In einigen Fällen enthielten die Submodule selbst verschachtelte Submodule. Diese verschachtelten Abhängigkeiten verweisen möglicherweise noch auf alte Bitbucket-URLs.
Um sicherzustellen, dass die interne Konfiguration von Git vollständig aktualisiert ist, führen Sie folgenden Befehl aus:
git submodule sync --recursive
Dieser Schritt ist besonders wichtig, wenn Sie mit bereits initialisierten Repositorys arbeiten.
Submodule bei bestimmten Commit-SHAs beibehalten
Einige Submodule wurden an bestimmte Commit-SHAs gebunden, um die Stabilität des Builds zu gewährleisten. Die Beibehaltung dieser Verweise ist für Firmware-Builds und reproduzierbare Pipelines von entscheidender Bedeutung.
Schritte zum Speichern eines bestimmten Commits:
cd submodule_path
git checkout <commit-sha>
Kehren Sie dann zum Haupt-Repository zurück:
git add submodule_path
git commit -m "Preserve submodule at specific commit SHA"
git push origin <branch-name>
Dadurch wird sichergestellt, dass das Repository weiterhin genau die Submodul-Version verwendet, die für den Build-Prozess erforderlich ist.
Was kommt als Nächstes: Migration von CI-Pipelines zu GitHub Actions
Damit ist Teil 1 unserer Serie über die Migrationsreise abgeschlossen.
Im nächsten Beitrag konzentrieren wir uns darauf, Projektabhängigkeiten sicher zu aktualisieren und sicherzustellen, dass die Builds und Pipelines, die wir migrieren wollen, weiterhin reibungslos funktionieren. Seid gespannt auf Teil 2!
Weitere Blogbeiträge findest du hier.