GitHub Migration: Chancen, Herausforderungen und Strategien

In der dynamischen Welt der Softwareentwicklung ist die Wahl des richtigen Tools entscheidend für den Erfolg eines Projekts. Azure DevOps und GitHub sind zwei der beliebtesten Plattformen, die von Entwicklern weltweit genutzt werden. Seit 2018 gehören beide Plattformen zu Microsoft. Ob und inwieweit Microsoft langfristig beide Plattformen betreiben wird oder diese in irgendeiner Weise zusammenführt ist aktuell unklar.  

Während Azure DevOps (ADO) eine umfassende Suite von Entwicklungs- und Projektmanagementwerkzeugen bietet, hat GitHub in den letzten Jahren durch seine benutzerfreundliche Oberfläche und starke Community zunehmend an Beliebtheit gewonnen. Außerdem bringt GitHub einige moderne Features wie GitHub Advanced Security oder den GitHub Copilot. Die Fülle an integrierten Features hat uns zu einer GitHub Migration überzeugt.

Nach gründlicher Analyse und Diskussion entschlossen wir uns, den eine GitHub Migration in Erwägung zu ziehen. Die Hauptgründe für diese Entscheidung waren: 

• Verbesserte Zusammenarbeit: GitHub bietet ein soziales Coding-Umfeld, das es Entwicklern ermöglicht, nahtlos zusammenzuarbeiten und Feedback zu geben.
• GitHub Copilot: Der KI-gestützte Programmierassistent, der Codevorschläge direkt beim Schreiben macht, steigert die Produktivität der EntwicklerInnen.
• GitHub Actions: Die Möglichkeit, CI/CD-Workflows direkt in GitHub zu erstellen und zu verwalten, ist ein großer Vorteil.
• Community und Support: Die große Entwickler-Community und der umfangreiche Support durch GitHub machen die Plattform attraktiv.
• GitHub Advanced Security: Eine Sammlung an zusätzliche Sicherheitsfeatures stellt beispielsweise Code Scans oder Abhängigkeitsprüfung zur Verfügung.
• GitHub Enterprise Billing: Die neue Abrechnungsplattform ermöglicht es, Kostenstellen zu erstellen und diesen spezifischen Benutzern, Organisationen oder Repositories zuzuweisen. 

Die Lizenzierung in GitHub Enterprise Cloud basiert auf einem sitzungsbasierten Modell, bei dem Benutzerlizenzen über ein Enterprise-Konto verwaltet werden. Hier sind die wichtigsten Punkte: 

Benutzerbasierte Lizenzen

• Jede Person mit Zugriff auf private Repositories unter einem Enterprise-Konto benötigt eine Lizenz.
• Lizenzen gelten für Nutzer, egal wie viele Organisationen oder Repositories sie innerhalb des Unternehmenskontos nutzen. 

Lizenzzuweisung

• Lizenzen werden automatisch zugewiesen, wenn ein Benutzer einer Organisation innerhalb des Enterprise-Kontos hinzugefügt wird.
• Administratoren können Lizenzen zentral über das Enterprise-Dashboard verwalten. 

Abrechnung

• Die Abrechnung erfolgt auf monatlicher oder jährlicher Basis, je nach Vertrag.
• Zusätzliche Lizenzen können bei Bedarf erworben werden und die Abrechnung passt sich entsprechend an. 

GitHub Advanced Security (GHAS)

• Funktionen wie Code-Scanning und Secret-Scanning erfordern eine zusätzliche Lizenz pro Benutzer. 

Zusätzliche Produkte

• Add-ons wie GitHub Copilot for Business oder Speicher für GitHub Actions werden separat abgerechnet. 

Das Security Dashboard in GitHub Enterprise Cloud bietet einen zentralen Überblick über Sicherheitsprobleme in Organisationen und Repositories. Basis dafür sind die GitHub Advanced Security Features: 

• Code-Scanning: Automatische Überprüfung von Code auf Sicherheitslücken
• Dependabot: Analyse von Abhängigkeiten in Projekten, um bekannte Sicherheitslücken zu erkennen
• Secret Scanning: Aufspüren von geheimen Schlüsseln oder sensiblen Informationen im Code
• Dependency Graph: Visualisierung von Projektabhängigkeiten
• Sicherheitswarnungen: Automatische Benachrichtigung bei Sicherheitsproblemen 

Azure Devops und Github unterscheiden sich unter anderem in ihrem strukturellen Aufbau. In der Grafik wird ersichtlich, dass GitHub eine übergeordnete Ebene “Enterprise” hat, welche die Organisationen klammert. Außerdem haben die “Projekte” eine unterschiedliche Bedeutung. Während im Azure DevOps “Projekt” eine organisatorische Klammer um Pipelines, Boards, Repositories usw. bildet, ist das Projekt innerhalb von GitHub eher vergleichbar mit den Boards in Azure DevOps und dient der WorkItem-Verwaltung. Die CI/CD-Prozesse finden sich im ADO unter dem Begriff Pipelines und werden auf Projektebene verwaltet. Im GitHub sind diese Prozesse mit Actions realisierbar und werden via Repository verwaltet.  Wenn man diese Strukturänderungen verstanden hat, fällt der Umstiegt auf GitHub direkt leichter und man findet sich auf der Plattform schnell zurecht. 

Repos

Azure DevOps unterstützt für die Versionskontrolle sowohl Git als auch Team Foundation Version Control (TFVC). Da TFVC im GitHub nicht mehr unterstützt wird, ist eine Migration zu Git erforderlich. Es gibt verschiedene Ansätze, um diese Migration durchzuführen. Sofern das zu migrierende Repository bereits in Git verwaltet wird und keine großen Dateien beinhaltet, ist die einfachste Möglichkeit hierbei der Import über die GitHub-Webseite. Für Repositories welche noch mit TFVC verwaltet werden, empfehlen sich externe Tools wie „git-tfs“. Alternativ ist es auch möglich, das Repository innerhalb von Azure DevOps zu Git zu migrieren und anschließend dann zu GitHub. Große Dateien können ebenfalls externe Tools wie „git-lfs“ erfordern. Um die Migrationszeit zu reduzieren ist es sinnvoll, die nicht mehr benötigten Branches vor der Migration zu bereinigen. 

CI / CD

Das Grundprinzip der Continuous Integration und Continuous Deployment (CI/CD) ist in beiden Welten das gleiche. Der Aufbau der GitHub Actions ist ähnlich zu den AOD YAML Pipelines, jedoch gibt es Unterschiede in der Syntax und dem Marketplace. Der GitHub Marketplace ist sehr Community-getrieben und bietet eine große Auswahl an Funktionen. 

Projekte / Workitems

Azure Boards sind sehr umfangreich und bieten diverse Auswertungsmöglichkeiten sowie gute Ausgangstemplates. Im Vergleich dazu sind die Möglichkeiten bei GitHub Projects etwas eingeschränkter. GitHub Projects bieten jedoch Basis Templates, die für viele Projekte gut und ausreichend sind. 

Die GitHub Migration hat sich für uns gelohnt – nicht nur technologisch, sondern auch kulturell. Die Plattform fördert offene Zusammenarbeit, bringt moderne Features und lässt sich flexibel in bestehende Toolchains integrieren. Natürlich war nicht alles reibungslos – aber mit einem klaren Migrationsplan und direkten Austausch zwischen IT und Fachbereichen lassen sich auch größere Plattformwechsel effizient umsetzen.