Die Sprache YAML ermöglicht es, CI/CD-Pipelines auf Microsoft Azure DevOps in Form von Code zu konfigurieren. Erfahre, warum und wie du dich für diesen Ansatz entscheiden solltest und welche Vorteile er gegenüber dem klassischen Editor bietet!
Durch das Hinzufügen von Pipelines zu seinem Cloud-Dienstleistungsangebot Azure DevOps hat Microsoft es ermöglicht, den Entwicklungsprozess um CI/CD-Praktiken (Continuous Integration and Delivery) zu erweitern.
Es gibt jedoch zwei Möglichkeiten, eine Azure Devops-Pipeline zu erstellen. Die erste Methode ist die Verwendung der „klassischen“ Tools, die zweite nutzt die neue, 2020 eingeführte Funktion der mehrstufigen YAML-Pipeline.
Was sind klassische Pipelines?
Was sind herkömmliche Pipelines? Eine Build-Pipeline wird beispielsweise ausgeführt, bevor ein Entwickler die Codeänderungen in die Codebasis integriert.
Die Pipeline kann eine Build-Aufgabe ausführen, Unit-Tests starten oder statische Code-Analysen durchführen. Sie kann dann je nach den Ergebnissen dieser Aufgaben neue Änderungen annehmen oder ablehnen.
Continuous Delivery (CD) wird über die Azure DevOps-Relax-Pipelines durchgeführt. Nachdem die Build-Pipeline ein Artefakt produziert hat, veröffentlicht eine Relax-Pipeline das Artefakt auf verschiedenen Umgebungen für manuelles funktionales Testen, User Experience Testing und Qualitätssicherung.
Wenn die Tester die eingesetzten Artefakte rigoros getestet haben, kann die Relax-Pipeline die Artefakte in die Produktionsumgebung schieben.
Diese klassischen CI/CD-Pipelines haben jedoch einige Nachteile. Zunächst einmal bieten die Werkzeuge zur Erstellung von Build- und Relax-Pipelines keine einheitliche Erfahrung.
CI-Pipelines bieten eine intuitive grafische Benutzeroberfläche zum Erstellen und Visualisieren von Integrationsschritten und ermöglichen es auch, dieselben Schritte in YAML zu definieren.
Relax-Pipelines bieten ebenfalls eine grafische Benutzeroberfläche zum Erstellen und Anzeigen von Pipeline-Schritten, aber das Problem ist, dass sich diese Benutzeroberfläche von der der Build-Pipeline unterscheidet und keine YAML-Definitionen zulässt.
Was sind mehrstufige Pipelines?
Um dieses Problem zu beheben, hat Microsoft die Multi-Step-Pipelines entwickelt. Diese Pipelines sind seit 2020 verfügbar und ermöglichen es einem Ingenieur, eine Build-, Relax- oder Hybrid-Pipeline in Form eines einzigen YAML-Dokuments zu definieren.
Neben dem Vorteil einer einheitlichen Entwicklungserfahrung bietet YAML viele Vorteile gegenüber herkömmlichen Pipelines. Und das sowohl für Builds als auch für Relaxes.
YAML-Definitionen werden direkt über die Versionskontrolle validiert, wodurch die gleichen Vorteile genutzt werden können, die Entwicklern seit Jahrzehnten durch die Versionskontrolle geboten werden.
Was ist YAML?
YAML ist eine Sprache zur Serialisierung von Daten, die oft zum Schreiben von Konfigurationsdateien verwendet wird. Ihr Name ist ein Akronym für „Yet Another Markup Language“.
Diese Programmiersprache ist beliebt, da sie leicht verständlich und für Menschen lesbar ist. Sie kann auch in Verbindung mit anderen Sprachen verwendet werden. Ihre Flexibilität und Zugänglichkeit sind ihre größten Stärken.
YAML übernimmt Merkmale aus verschiedenen Sprachen wie Perl, C, XML und HTML. Es verwendet auch die Einrückung im Stil von Python, um Nested anzuzeigen. Tabulatorzeichen sind nicht erlaubt, stattdessen werden Leerzeichen verwendet.
Es gibt keine üblichen Formatsymbole wie Klammern oder Anführungszeichen. YAML-Dateien haben die Erweiterung .yml oder .yaml und ihre Struktur ist eine Karte oder eine Liste.
Mit Karten können Paare von Schlüsseln und Werten verknüpft werden. Jeder Schlüssel muss eindeutig sein, aber die Reihenfolge spielt keine Rolle. Eine YAML-Karte muss aufgelöst werden, bevor sie geschlossen werden kann. Eine neue Karte wird erstellt, indem man die Einrückungsebene erhöht oder die vorherige Karte auflöst, um eine benachbarte Karte zu beginnen.
Eine Liste schließt Werte in einer bestimmten Reihenfolge ein und kann eine beliebige Menge der benötigten Elemente enthalten. Eine Listensequenz beginnt mit einem Dash (-) und einem Leerzeichen, und die Einrückung trennt sie von ihrem Elternteil. Man kann sie mit einer Python-Liste oder einem Bash- oder Perl-Array vergleichen. Eine Liste kann in eine Karte eingebettet werden.
Die YAML-Sprache nutzt auch Skalare: beliebige Daten, die in Unicode codiert sind und als Werte wie Strings, ganze Zahlen oder Datumsangaben verwendet werden können.
Neben dem Schreiben von Konfigurationsdateien, die einfacher und verständlicher als JSON sind, wird YAML häufig von den Ansible Playbooks für die Orchestrierung von IT-Prozessen und für Kubernetes-Einsätze verwendet.
Die Vorteile von YAML-Pipelines
Einer der Hauptvorteile von YAML-Pipelines ist die Möglichkeit, jede Änderung an der Pipeline seit ihrer Erstellung mithilfe der vom Versionsverwaltungssystem gebotenen Historie zu überprüfen.
Es ist auch möglich, eine dysfunktionale Definition mit der letzten bekannten funktionalen Definition zu vergleichen. Dadurch können Probleme im Build effizienter gelöst und die Wiederherstellungszeit verkürzt werden.
Ebenso kann es hilfreich sein, zu sehen, wer den fehlerhaften Code, der den Misserfolg verursacht hat, eingereicht hat und wer die Pull-Anfrage genehmigt hat.
Dadurch können die Teammitglieder einberufen werden, um mit ihnen nach dem besten Weg zur Behebung des Problems zu suchen und gleichzeitig sicherzustellen, dass die ursprünglichen Ziele erreicht werden.
Ein weiterer Pluspunkt: Die Arbeitselemente helfen dabei, herauszufinden, warum Änderungen vorgenommen wurden. Indem man an jeden Beitrag zur Pipeline eine Benutzeraufgabe anhängt, muss man sich nicht mehr an die Überlegungen erinnern, die zu einer bestimmten Änderung geführt haben.
Wenn eine Pipeline-Änderung zu Problemen führt, wie z. B. einer falsch konfigurierten QA-Umgebung, kannst du einfach zur letzten bekannten funktionalen Version zurückkehren. So wird deine QA-Umgebung innerhalb von Minuten wiederhergestellt.
Der eigentliche Vorteil von YAML ist, dass Entwickler die Anwendung, die Infrastruktur, aber auch die Build- und Relax-Pipelines als Code in einem einzigen Versionsverwaltungs-Repository haben können. Dies bietet einen vollständigen Snapshot des Systems für jeden beliebigen Zeitraum in der Vergangenheit.
Wenn man eine ältere Version des Repositoriums aufruft, kann man die Umgebung sehr einfach klonen, die gleichen Pipelines ausführen und den Code genau so einsetzen, wie er damals war. Dies ist eine sehr nützliche Funktion.
Außerdem wird das Teilen oder Duplizieren einer Pipeline mit einem einfachen Kopieren und Einfügen durchgeführt. Dabei handelt es sich um einen einfachen Text, der sogar per E-Mail an einen Kollegen geschickt werden kann, wenn er wiederverwendet werden soll.
CI/CD-Pipelines sind breit und komplex, und Änderungen an derselben YAML-Datei, die von mehreren Ingenieuren vorgenommen werden, können zu Konflikten führen. Glücklicherweise lösen Versionsverwaltungsplattformen dieses Problem, indem sie intuitive Werkzeuge zum Zusammenführen von konfliktbehafteten Änderungen bereitstellen. YAML-Definitionen ermöglichen es daher mehreren Ingenieuren, gleichzeitig an derselben Datei zu arbeiten.
Genau wie beim Anwendungscode ist auch bei Pipelines die Peer Review wichtig. Durch die Möglichkeit, eine Pull-Anfrage zu stellen, bevor neue Änderungen vorgenommen werden, können die Teammitglieder sicherstellen, dass die Änderungen den gewünschten Effekt haben.
Branching oder Verzweigung schließlich ermöglicht es, einen neuen Zweig zu schaffen, um untypische Ideen auszuprobieren. Von diesem Zweig aus kann eine Pipeline-Ausführung gestartet und wieder gelöscht werden, wenn sich die Idee als erfolglos erweist.
Die Einführung von vollständig textbasierten Pipeline-Definitionen, die über die Versionsverwaltung hinterlegt werden können, bringt Vorteile gegenüber den klassischen Definitionen, die auf einer grafischen Benutzeroberfläche basieren. Dies gilt insbesondere für große Organisationen, die gut daran tun, YAML für ihre nächste Azure DevOps-Pipeline-Implementierung in Betracht zu ziehen…
Herkömmliche Pipelines VS YAML: Der Vergleich
Klassische Pipelines werden über eine Benutzeroberfläche eingerichtet, indem du aus den angebotenen Optionen auswählst. Dies gilt sowohl für Build- als auch für Relax-Pipelines.
YAML-Pipelines wiederum werden mithilfe von Code in einer YAML-Datei konfiguriert. Der Azure DevOps Task Wizard kann dir dabei helfen, die benötigten Tasks zu finden und sie zur YAML-Datei hinzuzufügen.
Es ist durchaus möglich, eine Anwendung mithilfe von herkömmlichen Pipelines zu erstellen und einzusetzen. YAML-Pipelines ermöglichen jedoch den Einsatz in verschiedenen Umgebungen.
YAML-Pipelines vereinfachen die Zusammenarbeit und machen es leicht, mehrere Werte gleichzeitig zu ändern. Es ist z. B. möglich, das Suchwerkzeug einer IDE zu verwenden, um mehrere Vorkommen desselben Wertes zu finden und zu ersetzen.
Ein Versionsverwaltungswerkzeug wie git macht es auch sehr einfach, Änderungen zu vergleichen. Da sich die Pipeline in einer YAML-Datei im Repository befindet, ist es möglich, eine alte Version der Pipeline zusammen mit einer alten Version des Code-Repositorys wiederherzustellen.
YAML ist zur Standardoption für den Aufbau von Pipelines in Azure DevOps geworden, und die meisten CI/CD-Tools sind mit dieser Sprache kompatibel. Außerdem sind Container-Jobs exklusiv für YAML-Pipelines.
Andererseits kann dieser Ansatz mehr Zeit und Aufwand erfordern als herkömmliche Pipelines. Beachte dennoch, dass der Job-Assistent eine wertvolle Hilfe ist und dass es möglich ist, eine bestehende klassische Pipeline als YAML zu exportieren. Hierfür sind jedoch mehrere Anpassungen erforderlich.
Ein weiterer Schwachpunkt ist, dass einige Konfigurationen nicht in der Datei geändert werden können. Die Änderungen müssen über die Benutzeroberfläche vorgenommen werden, und die Option kann beim ersten Mal schwer zu finden sein.
Schließlich sind einige CD-Funktionen, die für Relax-Pipelines verfügbar sind, noch nicht für YAML-Pipelines verfügbar. Microsoft fügt jedoch nach und nach neue Funktionen hinzu.
Die klassischen Pipelines ihrerseits sind intuitiv und einfach zu bedienen. Es ist auch sehr einfach, die verschiedenen Optionen zu entdecken, indem man die Oberfläche mit der Maus erkundet, ohne auch nur einen Blick in die Dokumentation werfen zu müssen. Allerdings ist dies nicht mehr die Standardoption für den Aufbau von Pipelines für Azure DevOps.
Zusammenfassend lässt sich sagen, dass die Wahl zwischen der klassischen Pipeline und der YAML-Pipeline von deinen Bedürfnissen abhängt. Achte darauf, zu analysieren, wie die Pipelines in Gang gesetzt werden und auf welchen Umgebungen die Anwendung bereitgestellt wird, wie die Verzweigungsstrategie funktioniert und wie sie sich auf den Bereitstellungsablauf auswirkt.
Du solltest auch wissen, ob du eine einzige CI/CD-Pipeline oder zwei separate Pipelines benötigst. Achte auch darauf, dass du deinen Workflow und deine Anforderungen kennst.
Wie erstellt man eine CI/CD-Pipeline in YAML auf Azure DevOps?
Um eine CI/CD-Pipeline in YAML auf Azure DevOps zu erstellen, beginne zunächst damit, dich in ein Microsoft Azure-Konto einzuloggen, um Azure DevOps und Azure Pipelines zu nutzen.
Erstelle ein Teamprojekt, das auf Basic, Agile, Scrum oder CMMI basiert, und erstelle dann eine Build-Pipeline. Du musst die Quelle des Codes angeben und die IDs, mit denen man sich mit dem Code verbinden kann. Dabei kann es sich z. B. um ein GitHub-Repository handeln.
Nachdem du das Repository hinzugefügt hast, erhältst du Vorschläge für Templates, die auf verschiedenen Sprachen wie Java oder .Net basieren. Wähle ein Template aus, speichere die YAML-Datei (.yml) und aktiviere den Build. Es können beliebig viele Schritte und Jobs zur Pipeline hinzugefügt werden.
Der nächste Schritt besteht darin, eine Relax-Definition hinzuzufügen und die Webanwendung auf dem Azure Web App Service bereitzustellen. Wähle auf der Registerkarte „Relaxes“ die Option „Neue Pipeline“ und wähle die Vorlage für den App Service Deployment.
Du musst einen Web App Service auf Azure haben, um die Anwendung dort einzusetzen. Falls nicht, erstelle einen neuen über das Azure-Portal.
Um den Einsatz abzuschließen, müssen die im Build erstellten Artefakte unbedingt veröffentlicht werden. Dies erfordert, dass du der YAML-Datei eine Aufgabe hinzufügst, um die Artefakte am Ende zu veröffentlichen.
Bearbeite die Definition des Builds, gehe zum Ende der YAML-Datei, suche die Option zum Veröffentlichen von Build-Artefakten und klicke auf „Hinzufügen“. Speichere den Build und führe ihn aus, damit die Artefakte veröffentlicht und zum Relaxen verwendet werden können.
Es ist notwendig, den Build, aus dem die Artefakte stammen, für jede Relax-Definition bereitzustellen. Du musst daher die Aufgabe für den Azure App Service in der Relax-Definition einrichten und der Aufgabe erlauben, den erstellten Service mit deinem Azure-Konto zu nutzen. Speichere die Relax-Definition und erstelle eine Relax. Wenn die Bereitstellung abgeschlossen ist, solltest du die bereitgestellte Anwendung sehen.
Bearbeite anschließend die Build-Definition, um den Schalter für die kontinuierliche Integration und den Schalter für die kontinuierliche Bereitstellung zu aktivieren. Klicke einfach auf die Ellipsen-Schaltfläche und wähle die Schalter aus. Aktiviere und speichere die Schalter für die Relax-Definition und ändere den Code in GitHub, um sicherzustellen, dass beide Schalter wie gewünscht funktionieren. Speichere die Pipeline ab.
Anschließend kannst du die Build-Pipeline anpassen, indem du bei Bedarf Aufgaben hinzufügst oder bestehende Aufgaben änderst. Insbesondere ist es möglich, Variablen und Jobs hinzuzufügen.
Wie kann man Azure DevOps-Experte werden?
Der Aufbau von Pipelines in YAML ist nur eine der vielen Feinheiten von Azure DevOps. Um zu lernen, diese Plattform zu beherrschen, kannst du dich an DataScientest wenden.
In unserem Data Engineer-Kurs lernst du Techniken und Werkzeuge des Data Engineering kennen, darunter Python-Programmierung, CI/CD, Datenbanken, Big Data, Machine Learning oder auch Automatisierung und Deployment.
Wir bieten auch einen zertifizierenden Kurs für die Microsoft Azure Cloud an, der die Zertifizierungen AZ-104 Microsoft Azure Administrator und DP-203 Engineering on Microsoft ermöglicht. Beide Kurse können in nur fünf Tagen absolviert werden.
Alle unsere Kurse werden als Fernkurse, Intensiv-BootCamps oder Weiterbildungskurse durchgeführt. Unsere Organisation ist staatlich anerkannt und kann über den Bildungsgutschein finanziert werden. Entdecke DataScientest!
