『GitHub Actions, GitLab CI oder Jenkins: Was ist die beste Pipeline?』のカバーアート

GitHub Actions, GitLab CI oder Jenkins: Was ist die beste Pipeline?

GitHub Actions, GitLab CI oder Jenkins: Was ist die beste Pipeline?

無料で聴く

ポッドキャストの詳細を見る

【Amazonプライム会員限定】今ならプレミアムプランが4か月 月額99円。

10月19日まで。※適用条件あり
GitHub Actions, GitLab CI oder Jenkins – welche CI/CD-Plattform ist die richtige? Die Antwort hängt weniger von einzelnen Funktionen ab als von Repository-Struktur, Netzgrenzen, Security-Anforderungen und dem Team, das die Pipeline später betreiben muss. Denn die teuerste Pipeline ist nicht unbedingt die mit den höchsten Lizenzkosten, sondern die, die im Alltag niemand zuverlässig warten und verantworten kann. In dieser Folge von IT for Business vergleichen wir die drei Plattformen deshalb aus Betriebs- und Architektursicht.WAS EINE CI/CD-PIPELINE LEISTEN MUSSEine tragfähige Pipeline schafft einen kontrollierten Weg von einer Codeänderung bis zur laufenden Anwendung. Code wird geprüft, gebaut und getestet. Anschließend entsteht ein eindeutig versioniertes Artefakt oder Container Image.Entscheidend ist, dass genau dieser geprüfte Stand durch Test-, Staging- und Produktionsumgebungen wandert. Wird nach dem erfolgreichen Test für Produktion erneut gebaut, kann dort plötzlich ein anderer Stand landen.Eine Pipeline ist deshalb weit mehr als eine YAML-Datei. Sie ist Bestandteil der Betriebsarchitektur.SECURITY UND RUNNER VON ANFANG AN PLANENSecrets, Zertifikate und Zugangstoken gehören nicht in Quellcode oder Pipeline-Dateien. Ebenso wichtig sind nachvollziehbare Berechtigungen und getrennte Zugriffe für Entwicklung, Test und Produktion.Eine zentrale Rolle spielen Runner beziehungsweise Agents. Hosted Runner reduzieren den eigenen Infrastrukturaufwand. Self-hosted Runner ermöglichen dagegen den Zugriff auf interne Systeme und abgeschottete Netzwerke.Ein Runner mit Zugriff auf Produktionssysteme ist jedoch ein sicherheitskritischer Bestandteil der Infrastruktur. Patchmanagement, Segmentierung, Berechtigungen und Monitoring müssen entsprechend geplant werden.GITHUB ACTIONS: NAHELIEGEND FÜR GITHUB-TEAMSWenn der Quellcode bereits auf GitHub liegt, bietet GitHub Actions einen kurzen Weg zur Automatisierung. Workflows liegen direkt im Repository und können durch Pushes, Pull Requests, Releases oder manuelle Aktionen ausgelöst werden.Code, Reviews und Pipeline befinden sich dadurch nah beieinander. Besonders für Webanwendungen, APIs und Container-Workloads können Teams schnell eine funktionierende CI/CD-Strecke aufbauen.Mit wachsender Anzahl an Projekten werden jedoch gemeinsame Standards, Vorlagen und Verantwortlichkeiten notwendig.DER MARKETPLACE ALS SUPPLY-CHAIN-RISIKOGitHub Actions bietet zahlreiche fertige Actions aus dem Marketplace. Sie können die Implementierung erheblich beschleunigen.Dabei handelt es sich jedoch um externen Code, der innerhalb der eigenen Pipeline ausgeführt wird. Herkunft, Wartungszustand und benötigte Berechtigungen sollten deshalb geprüft werden.Versionen sollten außerdem kontrolliert fixiert werden, damit sich eine externe Abhängigkeit nicht unbemerkt verändert und dadurch zukünftige Produktionsläufe beeinflusst.GITLAB CI: DER PLATTFORMANSATZGitLab verbindet Repository, Merge Requests, Issues, Container Registry, Umgebungen und CI/CD stärker innerhalb einer gemeinsamen Plattform.Dadurch können Unternehmen Entwicklungs- und Deployment-Prozesse standardisieren und wiederverwendbare Pipeline-Vorlagen bereitstellen. Teams müssen dann nicht für jede Anwendung denselben Build-, Test- und Deployment-Prozess neu entwickeln.Besonders interessant kann GitLab sein, wenn die Plattform bereits als zentrale Entwicklungsumgebung eingesetzt wird oder Self-Hosting und interne Netzwerke eine wichtige Rolle spielen.SECURITY DIREKT IM ENTWICKLUNGSPROZESSGitLab kann – abhängig von Edition und Konfiguration – verschiedene Security-Prüfungen in den Entwicklungsprozess integrieren.Dadurch können beispielsweise Probleme mit Quellcode, Abhängigkeiten, Container Images oder Secrets bereits während eines Merge Requests sichtbar werden.Automatische Scanner ersetzen jedoch keine Security-Entscheidung. Unternehmen müssen definieren, welche Findings einen Release tatsächlich blockieren und welche zunächst bewertet werden müssen.JENKINS: MAXIMALE FLEXIBILITÄT MIT EIGENEM BETRIEBJenkins verfolgt einen anderen Ansatz. Unternehmen betreiben einen eigenen Automatisierungsserver und können Controller, Agents, Plugins und Integrationen sehr flexibel an die eigene Umgebung anpassen.Das kann bei älteren Anwendungen, speziellen Build-Systemen, abgeschotteten Netzwerken oder ungewöhnlichen Deployment-Prozessen ein großer Vorteil sein.Diese Freiheit erzeugt jedoch Betriebsaufwand. Jenkins benötigt Updates, Backups, Monitoring, Rechtekonzepte, Plugin-Pflege und Mitarbeiter, die die Plattform verstehen.DIE PLUGIN-FALLE BEI JENKINSDie große Erweiterbarkeit von Jenkins ist gleichzeitig eines der größten Betriebsrisiken.Plugins können unterschiedlich gepflegt sein, Sicherheitslücken enthalten oder nach Updates miteinander kollidieren. Über Jahre gewachsene Jenkins-Umgebungen enthalten außerdem häufig individuelle Skripte und Sonderlogik, deren ursprüngliche Entwickler ...
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません