In diesem Artikel rekapitulieren wir die Learnings eines Umzugs von Azure Pipelines auf GitHub Actions. Dabei stellen wir Pro und Contra der einzelnen Punkte gegenüber und versuchen die Frage zu klären: Lohnt sich ein Umzug auf GitHub Actions?
Wie bereits im einleitenden Artikel der Serie angeführt, befindet sich der Funktionsumfang von GitHub Actions weiterhin in der Entwicklung. Die Möglichkeit zum Beispiel Workflows manuell aus dem UI zu starten, existierte zum Zeitpunkt des Pipelineumzuges unserer AIT Voting Extension noch nicht. Insgesamt kann man jedoch davon ausgehen, dass man sich mit Erfahrungen in Azure YAML Pipeline sehr schnell in GitHub Actions zurechtfindet. Bis auf einige andere Bezeichner in der YAML–Datei sind die Strukturen grundlegend identisch. Die Unterschiede werden auch noch mal in der GitHub Actions Dokumentation ersichtlich.
Knackpunkt Berechtigungen
Der Teufel steckt aber wie so oft im Detail: Gerade das Berechtigungskonzept bereitet uns einiges an Kopfzerbrechen, da die Berechtigung zum Ausführen von Actions nicht separat eingestellt wird, sondern von der allgemeinen Rolle des Nutzers im Repository abhängt.
Somit sind die Trigger der Pipeline ausschlaggebend dafür, wer die Pipeline ausführen darf. Die Berechtigung der einzelnen Events lässt sich auch nur bedingt einstellen. Beispielsweise kann man auf das Vergeben von Stars für das Repository Workflows triggern. Dieses Event kann jeder registrierte GitHub Nutzer auslösen. Ein Trigger auf das Anlegen von Issues kann von jedem Nutzer mit Read Rechten ausgelöst werden, für den Pull Request Trigger benötigt man wenigstens Triage Rechte (siehe GitHub Doku). Deshalb sollte vor Verwendung eines Triggers immer der Nutzerkreis, welcher damit “Zugriff” auf die Pipeline bekommt, bedacht werden.
Hierbei muss man natürlich zwischen öffentlichen und privaten Repositories unterscheiden, da bei öffentlichen die Auswirkungen noch kritischer sein können. Wir empfehlen ein Berechtigungskonzept, welches Branch Policies, Nutzerrollen und Bedingungen in den YAML–Dateien nutzt, um den Zugriff auf die Workflows einzuschränken.
Variablen und Secrets
Die Verwaltung von Variablen und Secrets erfolgt ähnlich wie in Azure Pipelines, jedoch sind die Variablen immer an den jeweiligen Workflow gebunden und können nicht wie in Azure Pipelines in eine Variablengruppe ausgelagert werden. Dadurch kann man diese nicht so einfach wiederverwenden. Secrets sind an das Repository gebunden und somit für mehrere GitHub Actions nutzbar. Natürlich kann man wie in Azure Pipelines auch Actions nutzen, um die die Secrets aus externen Quellen, z.B. einem Azure Key Vault oder ähnlichem, zu holen.
Actions und Runners
Zur Verfügbarkeit von Actions lässt sich nur schwierig eine Aussage treffen. Für unsere bestehende Pipeline waren alle nötigen Actions vorhanden. Weiterhin ist es natürlich möglich eigene Actions zu entwickeln bzw. nicht vorhandene durch Skripte zu ersetzen. Ähnlich wie bei Azure Pipelines gibt es auch für GitHub Actions einen Marketplace, der aktuell über 4500 Actions anbietet.
Bei den Umgebungen bietet GitHub sowohl Linux und Microsoft als auch macOS Runner an. Dabei sind die unterschiedlichen Faktoren bei der Berechnung der Nutzungsminuten zu beachten: Während Linux Runner normal die Minuten berechnen (Faktor 1x), werden für Microsoft die doppelte Menge (Faktor 2x) an Minuten berechnet. Für den macOS Runner fallen sogar die 10-fache Menge an Minuten an. Es kann sich also durchaus lohnen einen self-hosted Runner mit dem entsprechenden Betriebssystem und Umgebung selbstbereitzustellen.
Fazit
Der Umzug von Azure Pipeline zu GitHub Actions ist mit mittelgroßem Aufwand möglich, jedoch darf die Bewertung des ggf. nötigen Wissensaufbaus nicht unterschätzt werden. Ob der Wechsel einen Nutzen bringt ist, stark vom Team als auch vom Projekt abhängig. Ein langfristige Wechsel von Azure DevOps auf GitHub kann außerdem ein Grund sein. Weiterhin sollte für das Deployment ins produktive System ein Berechtigungskonzept erarbeitet werden, um ein ungewolltes Deployment oder ein Deployment von unauthorisierten Benutzern auszuschließen.
Für die AIT Voting Extension konnten wir zum Zeitpunkt des Versuchs keinen vollwertigen Ersatz für unsere Azure Pipeline herstellen, da wir unser bestehendes manuelles Approval für das Produktivsystem nicht umsetzten konnten. Mit der Verfügbarkeit von manuellen Workflowtriggern wäre es jetzt möglich mit getrennten Actions für Test- und Produktivsystem ein ähnliches Konstrukt aufzubauen. Dabei wären die Jobs für Build und Deployment der Testumgebung vollautomatisiert und ausgelöst durch PRs bzw. Commits auf den Hauptbranch. Die Jobs des Produktivsystem würden manuell ausgelöst werden, wobei sie sich nur durch andere Variablen und Secrets von der Testumgebung unterscheiden würden.
Als letzter Punkt dieser Blogserie wird im nächsten Artikel ein Blick auf die automatisierte Analyse von Lizenzen und Sicherheitslücken im Source Code geworfen.
Sprechen Sie uns an, wenn Sie Fragen haben oder Unterstützung in Ihrem Softwareentwicklungsprozess benötigen: Von der ersten Idee über die Entwicklung mit einer Build– und Release-Pipeline bis hin zur Inbetriebnahme und Wartung. Wir führen Sie gerne ans Ziel.