Nach einigem Hin und Her haben wir uns entschieden, von unserer eigenen GitLab-Instanz zu GitHub zu wechseln. Aber warum? Und was hat uns bisher daran gehindert? Hier möchten wir einige Einblicke in unsere Entscheidung geben.
Zeit
Zeit ist ein ganz entscheidender Faktor während der Entwicklung, insbesondere, wenn man viel davon in seiner Freizeit macht. Zumindest wir möchten hier möglichst effizient arbeiten, um unsere freie Zeit möglichst gut zu nutzen.
GitLab erfordert, selbst gehostet, aber immer wieder Zeit. Seien es für Updates, die mindestens einmal monatlich erscheinen. Eher jedoch öfter, da es pro Monat schätzungsweise 3–5 Zwischenupdates gibt. Beim monatlichen Feature-Update kann auch gerne mal etwas kaputt gehen. Alle paar Monate muss dann wieder irgendetwas angepasst werden, nachdem erst einmal längere Zeit studiert werden muss, was nun wieder fehlerhaft ist und warum.
Das Deployment muss zu großen Teilen selbst geschrieben und dementsprechend auch selbst korrigiert werden, sollte irgendwas einmal nicht mehr passen.
Kurz: Man hat einen großen Dienst mehr, um den man sich selbst kümmern muss. Das alles fällt mit der Umstellung auf GitHub weg.
Interaktion
Auch wenn wir auf einige unserer kostenlosen Projekte Zugriff in GitLab gewährten: Die Hürde zur Registrierung und anschließender Kollaboration in einem privaten GitLab ist extrem hoch. Gleichzeitig hat aber fast jeder Entwickler ein GitHub-Konto. Die Interaktion mit anderen ist hier demnach wesentlich wahrscheinlicher und dann auch gleichzeitig höher, wodurch sowohl der Code am Ende besser wird als auch mehr Funktionalität erhalten kann.
Man hat letztendlich einfachen Zugriff auf eine große Entwickler-Community, die gleichzeitig auch noch hilft, die eigenen Projekte voranzutreiben.
Oberfläche
Zugegeben, die Benutzeroberfläche von GitLab und GitHub sind immer subjektiv bewertet. Und ja, auch GitHub hat schon ein paar größere Anpassungen dort gemacht. Allerdings im Vergleich zu GitLab eher wenige. Dort ändert sich gerne mal 2–3 mal im Jahr wieder etwas an der Oberfläche. Das mag zwar positiv sein, wenn sie besser durchdacht ist. Manchmal wird sie dadurch aber verkompliziert oder man findet erst einmal nicht mehr die eine Seite, auf die man gerne möchte.
Das hatten wir zumindest bei GitHub bisher nicht. Die Oberfläche ist hier wesentlich stimmiger und durchdachter. Und der neue Dark Mode ist natürlich das Tüpfelchen auf dem „i“.
Suche
Die Suche von GitLab ist, insbesondere im Vergleich zu selbiger in GitHub, einfach schlecht. Auch bei Suchbegriffen, die hundertprozentig ein Ergebnis liefern müssen, kann es sein, dass GitLab nichts findet. Das ist für eine Suche natürlich ziemlich problematisch und auch für den Suchenden.
Kosten
Einen eigenen Dienst zu betreiben heißt immer auch, eigene Hardware-Ressourcen bereitstellen zu müssen. Um es kurz zu halten: Durch die Migration zu GitHub können wir uns die Kosten für einen Server sparen.
GitHub Actions
GitHub Actions, das Äquivalent zur GitLab CI, beinhaltet schon viele vorgefertigte Actions – durch GitHub selbst und aus der Community. Daher ist der Aufwand, um ein für sich passendes Deployment zu bauen, gleichfalls einfach und schnell erledigt. Zumindest im Vergleich zur GitLab CI, in der man alles selbst entwickeln muss.
Zudem laufen die GitHub Actions auf sehr leistungsstarken Systemen, wodurch man hier weniger Einschränkungen hat.
Warum jetzt?
Gerade durch die GitHub Actions war ein großer Punkt – ein schnelles Deployment ohne externe Abhängigkeiten – der uns von einer Migration abgehalten hatte, kein Argument mehr. Dennoch brauchte es drei Anläufe für mich persönlich, mich intensiv mit der zugrunde liegenden Technik dahinter zu beschäftigen.
So nahm ich den Anlass, dass GitHub nun einen Dark Mode hat, das Ganze noch mal anzugehen. Und das war sehr erfolgreich. Mit rund einem Arbeitstag hatte ich alle erforderlichen Workflows für die GitHub Actions erstellt, die wir benötigen. Das gleiche Skript in GitLab zu bauen, hat damals wesentlich – wesentlich – länger gedauert.
Warum nicht GitLab.com?
Ganz einfach: Weil dort die Punkte Interaktion, Oberfläche und Suche nicht zutreffen und wir auch gar nicht wissen, ob wir unsere Deploy-Skripte dafür anpassen müssten. Das wäre auch wieder zusätzlicher Aufwand, das zu testen.
Wie?
Wir sind nicht die ersten, die von GitLab zu GitHub migrieren. Glücklicherweise haben sich die Kollegen von rtCamp damit bereits befasst und stellen ein PHP-Skript zur Verfügung, das für uns sehr gut funktioniert hat:
https://rtcamp.com/blog/gitlab-to-github-migration/
Damit konnten wir die Repositories, Labels, Milestones, Issues und Pull Requests erfolgreich übernehmen.
Fazit
Durch den Wechsel auf GitLab sparen wir insbesondere Zeit und Geld. Und durch die bessere Integration haben wir eine bessere Arbeitsweise und mehr mögliche Unterstützung aus der Community.