Die Software Dateien werden in einem zentralen Ort, einem Repository, mitsamt der \u00c4nderungshistorie auf GitHub gespeichert.\u00a0 Mithilfe von so genannten Branches k\u00f6nnen Entwickler parallel eigene Arbeitsstr\u00e4nge erstellen, in denen sie Ver\u00e4nderungen wie Fehler beheben oder neue Funktionen entwickeln k\u00f6nnen, ohne die Hauptversion des Projekts zu beeinflussen. \u00dcber Pull-Requests lassen sie die \u00c4nderungen des Branches nach \u00dcberpr\u00fcfung in die Hauptversion integrieren.<\/span><\/p>\n GitHub selbst bietet umfassende Zugriffskontrollmechanismen, welche es erm\u00f6glichen, unterschiedliche Berechtigungsstufen f\u00fcr Mitglieder zuzuweisen, um festzulegen, wer \u00c4nderungen vornehmen, Projekte verwalten oder nur Code einsehen darf. Repositories k\u00f6nnen entweder \u00f6ffentlich und f\u00fcr alle zug\u00e4nglich sein oder privat, sodass nur bestimmte Personen darauf zugreifen k\u00f6nnen. Neben der Zugriffskontrolle stellt GitHub eine Reihe weiterer Werkzeuge bereit, wie Fehlerverfolgung (Bug-Tracking), Aufgabenverwaltung (Task-Management), kontinuierliche Integration (Continuous Integration) und Wikis f\u00fcr Dokumentationen sowie Funktionen wie Pull-Requests, Code Scanning, GitHub Actions, GitHub Pages, Diskussionen und weiteren. Diese Werkzeuge und Funktionen helfen dabei, die Zusammenarbeit im Team zu verbessern, Entwicklungsprozesse zu automatisieren, Sicherheitsl\u00fccken zu minimieren und dadurch die Benutzerfreundlichkeit und Qualit\u00e4t von Softwareentwicklung zu steigern.<\/span><\/p>\n <\/p>\n GitHub Actions ist eine Automatisierungsplattform, mit der Softwareentwickler Workflows in einem GitHub-Repository erstellen k\u00f6nnen, welche wiederkehrende Aufgaben wie Tests, Builds und Deployments automatisieren. Diese Workflows werden bei einem bestimmten Trigger wie z.B Code-\u00c4nderungen oder Pull-Requests ausgef\u00fchrt und bestehen aus sogenannten Jobs, welche in einer YAML-Datei konfiguriert werden.<\/span><\/p>\n GitHub Actions stellt die integrierte L\u00f6sung f\u00fcr Continuous Integration (CI) und Continuous Deployment\/Delivery (CD) f\u00fcr GitHub dar. Mit CI werden Code\u00e4nderungen automatisch getestet, um sicherzustellen, dass \u00c4nderungen eines Branch bestehende Funktionalit\u00e4ten nicht beeintr\u00e4chtigen. CD erm\u00f6glicht es hingegen, getestete Code\u00e4nderungen in eine Staging- oder Produktionsumgebung \u00fcberf\u00fchren. GitHub Actions erm\u00f6glicht es, beide Prozesse innerhalb eines Repositories zu konfigurieren und durchzuf\u00fchren, wodurch externe CI\/CD-Tools oft \u00fcberfl\u00fcssig werden.<\/span><\/p>\n Die direkte Integration von GitHub Actions in GitHub bietet einige Vorteile. Zum einen wird f\u00fcr das Entwickeln und Verwalten der Workflows keine externen Tools ben\u00f6tigt, was Zeit spart und den Aufwand f\u00fcr die Einrichtung und Verwaltung zus\u00e4tzlicher CI\/CD-Tools.\u00a0 F\u00fcr \u00f6ffentliche Repositories bietet GitHub kostenloses Nutzungsvolumen f\u00fcr die Ausf\u00fchrung von Workflows, was es attraktiv f\u00fcr Open-Source-Projekte macht. Zudem existiert bereits eine gro\u00dfe Bibliothek an Actions, welche Entwickler wiederverwenden k\u00f6nnen, um h\u00e4ufige Aufgaben wie das Testen von Code, das Erstellen von Docker-Containern oder das Ver\u00f6ffentlichen der Software zu automatisieren.<\/span><\/p>\n Ein Workflow ist eine YAML-basierte Konfiguration, die den Ablauf einer oder mehrerer Aktionen beschreibt, die durch spezifische Events in einem GitHub-Repository ausgel\u00f6st werden. Workflows sind die oberste Einheit, in welcher automatisierte Build-, Test- und Bereitstellungspipelines f\u00fcr ein Repository definiert werden.\u00a0<\/span><\/p>\n Workflows lassen sich grob in drei Komponenten einteilen. Der Trigger bzw. das\u00a0 Ereignis definiert, welche Bedingung die Ausf\u00fchrung eines Workflows startet. Der Auftrag beinhaltet die eigentlichen Arbeitsschritte des Workflows. Diese Arbeitsschritte k\u00f6nnen einzelne Shellbefehle bzw. Shellscripts sein. Ebenso k\u00f6nnen hier jedoch auch sogenannte Aktionen, also extern definierte Prozesse, im Auftrag enthalten sein. Die dritte Komponente eines Workflows ist der Runner. Diese definiert, auf welchem Server der Workflow ausgef\u00fchrt wird. GitHub bietet kostenlos virtualisierte Linux-, Windows- und macOS-Computer an, alternativ k\u00f6nnen jedoch auch selbst gehostete Runner angegeben werden.<\/span><\/p>\n Es gibt prinzipiell vier Arten von Ereignissen, welche einen Workflow ausl\u00f6sen k\u00f6nnen:<\/span><\/p>\n Liste aller Ereignisse<\/a><\/p>\n Ereignisse mit Ursprung im Repository sind die g\u00e4ngigsten Trigger, fast alle verf\u00fcgbaren Ereignisse sind in dieser Kategorie. Typische Beispiele sind Push, Pull Requests oder ge\u00f6ffnete Issues. Viele Ereignisse k\u00f6nnen mit weiteren optionalen Attributen spezifiziert werden. Im vorherigen Beispiel wurde das Pull Request-Ereignis auf den main-Branch sowie auf alle Branches beginnend mit „releases\/“ beschr\u00e4nkt. Mit dem Mithilfe von Zuletzt existiert Konkreter Aufbau des Repository Dispatch API-Aufrufs<\/a><\/p>\n Innerhalb einer Workflow-Datei k\u00f6nnen beliebig viele dieser Trigger innerhalb der Innerhalb eines Workflows muss angegeben werden, welche Handlungen durchgef\u00fchrt werden sollen. Prinzipiell sind diese strukturiert durch zwei Einheiten:<\/p>\n Mithilfe des Es gibt zwei Arten von Steps:<\/p>\n Runner sind spezialisierte Maschinen, die sowohl virtuell als auch physisch bereitgestellt werden k\u00f6nnen und eine zentrale Rolle bei der Automatisierung von GitHub-Workflows spielen. Sie sind darauf ausgelegt, verschiedene Aufgaben eines Workflows zu \u00fcbernehmen, wie beispielsweise das Klonen eines Repositories, das Installieren von Abh\u00e4ngigkeiten, das Ausf\u00fchren automatisierter Tests und das Erstellen oder Bauen von Anwendungen. Durch diese Automatisierung erm\u00f6glichen Runner eine nahtlose Integration und kontinuierliche Bereitstellung (CI\/CD), wodurch Entwicklungsprozesse effizienter gestaltet werden.<\/span><\/p>\n GitHub bietet Nutzern die Wahl zwischen der Verwendung von Runnern auf eigener Hardware und der Nutzung der von GitHub bereitgestellten Infrastruktur. Die von GitHub zur Verf\u00fcgung gestellten Runner laufen auf leistungsf\u00e4higen virtuellen Maschinen, die speziell f\u00fcr eine Vielzahl von Anwendungsf\u00e4llen optimiert sind. Diese virtuellen Maschinen sind in verschiedenen Betriebssystem-Umgebungen verf\u00fcgbar, darunter Ubuntu Linux, Windows und MacOS. Jede dieser Umgebungen ist mit vorinstallierten Tools und Bibliotheken ausgestattet, die h\u00e4ufig in Entwicklungsprojekten ben\u00f6tigt werden, was den Setup-Prozess erheblich vereinfacht.<\/span><\/p>\n Ein besonders gro\u00dfer Vorteil der von GitHub bereitgestellten Runner liegt in ihrer Wartungsfreiheit. Die gesamte Pflege, einschlie\u00dflich der Aktualisierung der Betriebssysteme und der installierten Tools, wird von GitHub \u00fcbernommen. Dadurch entf\u00e4llt f\u00fcr die Nutzer der Aufwand, sich um die Instandhaltung oder Aktualisierung der Systeme zu k\u00fcmmern. Dies macht die Nutzung dieser Runner ideal f\u00fcr Entwicklerteams, die sich vollst\u00e4ndig auf ihre Projekte konzentrieren m\u00f6chten, ohne Zeit und Ressourcen f\u00fcr die Verwaltung der Infrastruktur aufzuwenden. Im Gegensatz dazu erfordert der Einsatz von Runnern auf eigener Hardware eine eigenverantwortliche Wartung und regelm\u00e4\u00dfige Updates, was zus\u00e4tzlichen Verwaltungsaufwand mit sich bringt, aber gleichzeitig mehr Kontrolle \u00fcber die Infrastruktur erm\u00f6glicht.<\/span><\/p>\n Die Matrix-Strategie ist ein leistungsstarkes Konzept, das die automatische Ausf\u00fchrung verschiedener Variationen eines GitHub-Workflow-Jobs erm\u00f6glicht. Sie erlaubt es, eine einzige Job Definition zu verwenden, die durch unterschiedliche Variablen angepasst wird, um mehrere Konfigurationen abzudecken. Ein typisches Beispiel ist das Testen oder Ausf\u00fchren einer Anwendung auf verschiedenen Betriebssystemen wie Linux und Windows. Hierbei wird das Betriebssystem nicht manuell festgelegt, sondern dynamisch durch die Matrix-Strategie gesteuert, sodass GitHub Actions automatisch mehrere Varianten des Jobs parallel ausf\u00fchrt.<\/span><\/p>\n Der wesentliche Vorteil dieser Strategie liegt in ihrer Effizienz und Flexibilit\u00e4t. Entwickler k\u00f6nnen mit minimalem Aufwand verschiedene Anwendungsf\u00e4lle testen oder ausf\u00fchren, ohne jeden einzelnen Workflow-Schritt mehrfach definieren zu m\u00fcssen. So k\u00f6nnen beispielsweise Kompatibilit\u00e4tstests, die auf unterschiedlichen Plattformen durchgef\u00fchrt werden m\u00fcssen, in einem einzigen Workflow abgedeckt werden. Dar\u00fcber hinaus spart die parallele Ausf\u00fchrung der Job-Varianten Zeit, da alle definierten Kombinationen gleichzeitig verarbeitet werden, anstatt sie nacheinander auszuf\u00fchren.<\/span><\/p>\n Die Matrix-Strategie eignet sich besonders f\u00fcr Projekte, bei denen Anwendungen plattform\u00fcbergreifend entwickelt oder getestet werden m\u00fcssen. Sie erm\u00f6glicht eine nahtlose Integration in bestehende Workflows und reduziert den Verwaltungsaufwand erheblich, da GitHub Actions automatisch alle m\u00f6glichen Kombinationen auf Basis der definierten Variablen erstellt und ausf\u00fchrt. Dies macht die Matrix-Strategie zu einem unverzichtbaren Werkzeug f\u00fcr Teams, die eine breite Testabdeckung erreichen m\u00f6chten, ohne dabei die Komplexit\u00e4t ihrer Workflow-Konfigurationen zu erh\u00f6hen.<\/span><\/p>\n Dieser GitHub-Workflow definiert einen Build-Job, der mit Hilfe der Matrix-Strategie parallel auf mehreren Betriebssystemen ausgef\u00fchrt wird. Die unterst\u00fctzten Plattformen sind Ubuntu, Windows und macOS, jeweils in ihrer neuesten Version. Der Workflow besteht aus zwei zentralen Schritten: Zun\u00e4chst wird der Quellcode des Repositories mit der GitHub Action actions\/checkout@v2 in den Arbeitsbereich geladen. Anschlie\u00dfend werden die Tests der Anwendung mit dem Befehl npm test ausgef\u00fchrt.<\/span><\/p>\n Dank der Matrix-Strategie wird der Job automatisch f\u00fcr jedes der definierten Betriebssysteme parallel gestartet. Dies erm\u00f6glicht eine plattform\u00fcbergreifende Validierung der Anwendung, wodurch sichergestellt wird, dass sie auf allen wichtigen Betriebssystemen einwandfrei funktioniert. Die parallele Ausf\u00fchrung spart dabei Zeit und erh\u00f6ht die Effizienz des Workflows. Durch die einfache Konfiguration mit einer einzigen Job-Definition wird zudem der Wartungsaufwand reduziert, da keine separate Konfiguration f\u00fcr jedes Betriebssystem erforderlich ist. Dieser Workflow ist besonders n\u00fctzlich f\u00fcr Node.js-Projekte, die auf zuverl\u00e4ssige Funktionalit\u00e4t \u00fcber verschiedene Plattformen hinweg angewiesen sind.<\/span><\/p>\n <\/p>\n GitHub Pages ist ein kostenloser Hosting-Dienst von GitHub, der speziell f\u00fcr die Ver\u00f6ffentlichung statischer Websites wie HTML-, CSS- und JavaScript-Dateien konzipiert wurde. Entwickler k\u00f6nnen damit Projekte, Dokumentationen oder pers\u00f6nliche Webseiten direkt aus einem GitHub-Repository heraus online zug\u00e4nglich machen. Dazu muss in den Repository-Einstellungen die Option f\u00fcr GitHub Pages aktiviert und der gew\u00fcnschte Branch ausgew\u00e4hlt werden. Die notwendigen Quelldateien k\u00f6nnen einfach hochgeladen oder mithilfe von Jekyll (siehe GitHub Docs)<\/a>, einem statischen Webseiten-Generator mit direkter Unterst\u00fctzung f\u00fcr GitHub Pages, erstellt werden. Nach der Einrichtung ist die ver\u00f6ffentlichte Webseite unter einer automatisch generierten URL erreichbar.<\/span><\/p>\n Dabei unterliegt GitHub Pages einigen Einschr\u00e4nkungen, die Nutzer beachten sollten. Der Dienst darf nicht f\u00fcr kommerzielle Zwecke verwendet werden und muss den GitHub-Nutzungsbedingungen\u00a0(Terms of Service)<\/a> entsprechen. Au\u00dferdem darf die Webseite nicht mehr als 1 GB Speicherplatz belegen und die Bandbreite ist auf 100 GB pro Monat begrenzt. Pro Stunde sind maximal 10 Builds erlaubt, was vor allem bei h\u00e4ufigen \u00c4nderungen ber\u00fccksichtigt werden muss. Zus\u00e4tzlich gelten allgemeine Rate-Limiting-Regeln, die sicherstellen, dass der Dienst fair und effizient genutzt wird (siehe Einschr\u00e4nkungen von GitHub Pages)<\/a>.<\/span><\/p>\n <\/p>\n Das Repository\u00a0github-ci-cd-example<\/a> dient als Beispiel zur Implementierung von Continuous Integration (CI) und Continuous Deployment (CD) Workflows mit GitHub Actions. Es demonstriert, wie Projekte automatisiert gebaut, getestet und bereitgestellt werden k\u00f6nnen.<\/p>\n Wichtige Merkmale des GitHub Workflows:<\/p>\n Der Workflow ist klar strukturiert und nutzt bew\u00e4hrte Praktiken zur Automatisierung von Softwareentwicklungsprozessen. <\/p>\n GitHub Actions ist ein vielseitiges und leistungsstarkes Tool zur Automatisierung von Softwareentwicklungsprozessen direkt in GitHub. Es erm\u00f6glicht die nahtlose Integration von Continuous Integration (CI) und Continuous Deployment (CD), wodurch Code\u00e4nderungen effizient getestet und bereitgestellt werden k\u00f6nnen. Die intuitive Konfiguration \u00fcber YAML-Dateien und die breite Auswahl an vorgefertigten Actions machen es sowohl f\u00fcr kleine Open-Source-Projekte als auch f\u00fcr gro\u00dfe Entwicklungsteams attraktiv.<\/p>\n Die Vorteile der nativen Integration, wie die Nutzung GitHub-gehosteter Runner und die Unterst\u00fctzung durch eine umfangreiche Community, sparen Zeit und reduzieren Komplexit\u00e4t. Funktionen wie die Matrix-Strategie und die einfache Anpassung an unterschiedliche Workflows bieten zudem eine hohe Flexibilit\u00e4t. F\u00fcr Entwicklerteams, die eine robuste, einfach zu bedienende und kosteneffiziente CI\/CD-L\u00f6sung suchen, stellt GitHub Actions eine erstklassige Wahl dar.<\/p>\n Trotzdem gibt es Alternativen wie GitLab CI\/CD, Jenkins oder Azure Pipelines, die je nach spezifischen Anforderungen ebenfalls in Betracht gezogen werden k\u00f6nnen. GitHub Actions punktet jedoch besonders durch die enge Integration in GitHub und die einfache Handhabung, was es zu einem bevorzugten Werkzeug f\u00fcr viele Entwickler macht.<\/p>\n <\/p>\n GitHub GitHub ist eine cloud-basierte Plattform, die es Entwicklern erm\u00f6glicht, Code zu hosten, zu teilen und gemeinsam daran zu arbeiten.<\/p>\n","protected":false},"author":179,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3608","post","type-post","status-publish","format-standard","hentry","category-betriebliche-informationssysteme"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3608","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/179"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=3608"}],"version-history":[{"count":25,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3608\/revisions"}],"predecessor-version":[{"id":4060,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3608\/revisions\/4060"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=3608"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=3608"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=3608"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}GitHub Actions<\/h1>\n
Was sind GitHub Actions<\/span><\/h2>\n
CI\/CD mit GitHub Actions<\/span><\/h2>\n
Vorteile der nativen GitHub Actions-Integration<\/span><\/h2>\n
Bestandteile von GitHub Actions<\/span><\/h2>\n
Workflows<\/span><\/h3>\n
Trigger<\/span><\/h3>\n
\n
![\"\"](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2025\/03\/wfall-274x300.png\")
<\/p>\n
\nTypische Anwendungsf\u00e4lle sind beispielsweise die Erstellung von Releases oder die Ausf\u00fchrung diverser Tests f\u00fcr Codekompatibilit\u00e4t und -qualit\u00e4t.<\/span><\/p>\nschedule<\/code>-Trigger kann mit typischer cron-Syntax definiert werden, dass ein Workflow nach einem Zeitplan ausgef\u00fchrt wird. Hier ist zu beachten, dass die kleinste Zeiteinheit die Minute ist, und dass dieser Trigger maximal alle 5 Minuten eine Workflowausf\u00fchrung starten kann.<\/p>\nworkflow_dispatch<\/code> wird erlaubt, dass ein Workflow manuell gestartet werden kann. Dieser Trigger wird h\u00e4ufig verwendet, um im Fehlerfall w\u00e4hrend der Ausf\u00fchrung leicht eine Neuausf\u00fchrung anzusto\u00dfen.<\/span><\/p>\nrepository_dispatch<\/code>. Dieses Ereignis erlaubt, dass Ereignisse au\u00dferhalb des Repositories mithilfe eines API-Aufrufs akzeptiert werden. Mithilfe eines Tokens, der f\u00fcr Workflowausf\u00fchrungen autorisiert ist, kann ein POST-Request an die GitHub API-URL f\u00fcr das Repository gesendet werden. Dort muss im JSON-K\u00f6rper ein frei w\u00e4hlbarer Event-Typ (als String) \u00fcbergeben werden. Wenn in der Workflowdatei kein types: [...]<\/code> Attribut \u00a0definiert ist, wird das Ereignis immer ausl\u00f6sen, ungeachtet des Typs im API-Aufruf. Ansonsten l\u00f6st es nur aus, wenn der Eventtyp im Request auch hier in der Workflowdatei vorhanden ist.<\/p>\non:<\/code>-Eigenschaft aufgef\u00fchrt werden.<\/span><\/p>\nAuftrag<\/span><\/h3>\n
\n
needs: [...]<\/code>-Feld eines Jobs kann definiert werden, dass dieser auf die Fertigstellung eines anderen Jobs warten muss. Dadurch werden zumindest diese zwei Jobs sequentiell ausgef\u00fchrt, und ein Fehler im ersten Job verhindert die Ausf\u00fchrung des Zweiten.
\nEbenso kann das Fehlerverhalten f\u00fcr Steps \u00fcberschrieben werden: ein gesamter Job oder ein einzelner Step kann mit continue-on-error:<\/span> true<\/span><\/code> versehen werden. In Folge wird ein Fehler zwar angezeigt, aber darauffolgende Steps immer ausgef\u00fchrt.<\/p>\nArten von Steps<\/span><\/h3>\n
![\"\"](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2025\/03\/shell-300x179.png\")
<\/p>\n![\"\"](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2025\/03\/action-300x181.png\")
<\/p>\n\n
run<\/code> definiert, als Wert kann dann eine einzelne Zeile oder ein mehrzeiliges Shellscript ausgef\u00fchrt werden. Es kann global oder pro Step definiert werden, welcher Shell-Interpreter und welches Working Directory zu verwenden ist. Standardm\u00e4\u00dfig wird auf Windows-Runnern PowerShell und auf anderen Runnern Bash oder die Z-Shell verwendet.<\/li>\nuses<\/code> definiert. Es wird jedoch anstelle von direkten Shellbefehlen eine vordefinierte Sammlung von komplexeren Handlungen aufgerufen. Actions k\u00f6nnen mithilfe von JavaScript implementiert werden (bspw. die checkout@v4<\/code> Action im Beispiel), alternativ k\u00f6nnen Actions aber auch mithilfe von Docker beliebig implementiert werden. Docker-basierte Actions sind praktisch beliebig m\u00e4chtig, haben jedoch eine langsamere Startzeit als JS-basierte Actions.
\nZuletzt existieren zusammengesetzte Aktionen, welche praktisch eine separate Workflowdatei ohne Trigger sind. Dort k\u00f6nnen erneut Jobs und Steps definiert werden, ebenso k\u00f6nnen Parameter mithilfe des inputs:<\/code>-Feld \u00fcbergeben werden.<\/li>\n<\/ul>\nGithub Runner<\/span><\/h3>\n
Github Runner Matrix Strategie<\/span><\/h3>\n
Workflow Konfiguration<\/span><\/h3>\n
![\"\"](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2025\/12\/2025-01-04T11-52-11Z_code-300x117.png\")
<\/p>\nGithub Pages<\/span><\/h1>\n
Beispiel Konfiguration<\/h2>\n
\n
\nWeitere Informationen und der vollst\u00e4ndige Code sind verf\u00fcgbar unter: https:\/\/github.com\/jokresner\/github-ci-cd-example<\/a><\/p>\nAlternativen<\/span><\/h1>\n
Gitlab CI\/CD\u00a0(Gitlab CI\/CD Dokumentation)<\/a><\/span><\/h2>\n
\n
Jenkins\u00a0(Jenkins Dokumentation)<\/a><\/span><\/h2>\n
\n
Microsoft Azure Pipeline\u00a0(Azure Pipelines Dokumentation)<\/a><\/span><\/h2>\n
\n
Fazit<\/span><\/h1>\n
Quellen<\/span><\/h1>\n
\n