Welche Rolle spielt Build-Automatisierung bei DevOps?
Die automatisierte Build-Erstellung spielt eine zentrale Rolle bei der Automatisierung von Continuous Integration (CI) und ist ein grundlegender Bestandteil einer CI/CD-Pipeline. Sie ist der erste in einer Reihe von automatisierten Schritten, die Sie so früh wie möglich warnen sollen, wenn Ihre neuesten Codeänderungen Probleme verursachen.
In diesem Zusammenhang meinen wir mit „Build“ mehr als nur das Kompilieren und Linken des Quellcodes zur Erstellung einer ausführbaren Datei.
Der automatisierte Buildprozess umfasst außerdem eine Reihe von Prüfungen sowie das Zusammenführen aller Komponenten, die für die Ausführung Ihres Programms erforderlich sind. Daher wird selbst bei einer interpretierten Sprache ein Build-Schritt benötigt.
Die Dateien, die aus der Build-Phase hervorgehen – die sogenannten Build-Artefakte – durchlaufen dann in der CI/CD-Pipeline weitere Testphasen sowie ein anschließendes Staging. Wenn ein Build jeden Schritt in der Pipeline erfolgreich durchlaufen hat, ist er für die Veröffentlichung bereit.
Warum Builds und Deployments automatisieren?
Bevor wir uns dem Aufbau der Build-Automatisierung widmen, wollen wir der Frage nachgehen, warum ein automatisierter Build-Management-Prozess wichtig ist.
Wenn wir in einer IDE arbeiten, können wir einen Buildvorgang normalerweise mit einer simplen Tastenkombination auslösen. Warum also den Prozess automatisieren?
Erstens: Lokale Builds sind zwar sehr praktisch, um die eigene Arbeit zu überprüfen oder schnell etwas vorzuführen. Es ist jedoch nicht sinnvoll, lokale Builds für Ihre CI/CD-Pipeline zu verwenden.
Die Verwendung eines dedizierten Build-Servers sorgt für eine saubere Umgebung und eine schnelle Erkennung aller fehlenden Abhängigkeiten, die sonst Probleme und Verzögerungen verursachen würden, wenn das Build-Ergebnis in einer Testumgebung bereitgestellt wird.
Ohne einen automatisierten Build-Schritt als Auftakt für die anderen Phasen der Pipeline wäre der CI/CD-Ablauf viel weniger verlässlich. Wenn wir daran denken müssen, uns beim Build-Server anzumelden und jeden Build einschließlich aller Tests zu starten, den Prozess zu beaufsichtigen, um eventuelle Fehler mitzubekommen, und die ausgegebenen Artefakte in das Artefakt-Repository zu verschieben, damit sie zum Testen bereitgestellt werden können, haben wir einen fehleranfälligen Prozess.
Es ist verlockend, den Build aufzuschieben, bis ein paar weitere Änderungen zum Testen zusammenkommen, aber dies würde die Vorteile von CI/CD untergraben.
Außerdem besteht die Strategie hinter einer CI/CD-Pipeline darin, Fehler möglichst früh zu erkennen.
Je früher Sie von einem Problem erfahren, desto einfacher ist die Behebung und desto effizienter ist Ihr Build-Automatisierungsprozess. Eine automatisierte Build-Phase ist schneller als das manuelle Auslösen der verschiedenen Schritte und viel schneller als das Verschieben von Dateien und das Ausführen von Tests von Hand.
Durch die Automatisierung des Buildvorgangs stellen Sie sicher, dass bei jedem einzelnen Commit (oder einem Batch von Commits) alle Schritte in der richtigen Reihenfolge ausgeführt werden. Sie profitieren von einem schnelleren Feedback und sparen dabei auch noch Zeit.
Wie funktioniert die Build-Automatisierung in Ihrer CI/CD-Pipeline?
Wenn Sie neu in CI/CD einsteigen, müssen Sie, nachdem Sie den gesamten Codebestand in eine Versionsverwaltung überführt haben, als einen der ersten Schritte automatisierte Builds einrichten, die jedes Mal ausgelöst werden, wenn ein Teammitglied einen Commit vornimmt. Vielleicht haben Sie bereits ein Buildskript oder eine Definitionsdatei, entweder selbst geschrieben oder von Ihrer IDE erstellt.
Ist dies nicht der Fall, müssen Sie ein geeignetes Build-Automatisierungs-Tool für die verwendete Sprache auswählen und die Dateien angeben, die kompiliert, verlinkt und zu Paketen gebündelt werden sollen. Anschließend können Sie einen CI-Server verwenden, um die verschiedenen Schritte zu koordinieren, vom ersten Auslöseereignis bis hin zum Bereitstellen von Feedback und der Definition der Fehlerbedingungen.
Auslösen eines Builds
Bei der automatisierten Continuous Integration wird nach jeder Übergabe an Master ein Build ausgelöst, sodass jede Änderung kurz nach ihrer Erstellung integriert und getestet wird. Wenn der Buildvorgang erfolgreich abgeschlossen wurde, wird der nächste Prozessschritt ausgelöst.
In den meisten CI-Tools können Sie zusätzliche Build-Trigger konfigurieren und die anschließenden Pipeline-Phasen anpassen.
Zum Beispiel könnten Sie die gleichen Schritte auslösen, wenn Commits in Branches in einem bestimmten Verzeichnis vorgenommen werden. Andererseits möchten Sie vielleicht mithilfe eines Deployment-Tools einen Nightly-Build einrichten, der jede Nacht erstellt wird, zusätzliche Testschichten durchläuft und zum Aktualisieren von Staging-Umgebungen verwendet wird. Außerdem können Sie die Build-Phase auch manuell einleiten.
Ausführen eines Builds
Es empfiehlt sich, die Build-Schritte auf einem dedizierten Build-Server statt auf Ihrem Entwicklungssystem auszuführen. Indem der Build in einer sauberen Umgebung erstellt wird, werden fehlende Abhängigkeiten erkannt und Probleme wie „Auf meinem System funktioniert es aber“ vermieden.
Der Build-Schritt ruft das gewählte Build-Automatisierungs-Tool (z. B. Maven, Ant oder Gradle) auf, das die im Buildskript oder in der Definitionsdatei angegebenen Aufgaben ausführt.
Sobald Sie wissen, wie lange der Buildvorgang ungefähr dauert, sollten Sie mit einem Deployment-Tool eine Fehlerbedingung konfigurieren, die ausgelöst wird, wenn der Vorgang nicht innerhalb eines bestimmten Zeitraums abgeschlossen wird. Dadurch vermeiden Sie, dass ein schiefgelaufener Buildvorgang Ihre Ressourcen über längere Zeit blockiert.
Durchführen von Tests
Der automatisierte Build-Management-Prozess bereitet nicht nur Ihren Code für die Bereitstellung vor. Er ist auch ein idealer Ausgangspunkt für eine Reihe weiterer Codeprüfungen – z.B. Unit-Tests, Linting und statische Codeanalysen. Wenn Sie diese Prüfungen im Rahmen jedes Buildvorgangs mit einem Deployment-Tool ausführen und auftretende Probleme beheben, wird sich die Qualität Ihres Codes verbessern.
Obwohl diese Prüfungen vor dem Erzeugen der Build-Artefakte stattfinden, muss ein Fehler nicht unbedingt den restlichen Ablauf der Pipeline unterbrechen. Sie könnten beispielsweise entscheiden, dass Sie Build-Artefakte auch dann veröffentlichen und mit der nächsten Pipeline-Phase fortfahren möchten, wenn Linting-Fehler gefunden wurden. Durch das Konfigurieren einer Qualitätsschwelle können Sie dabei verhindern, dass sich „kleine“ Probleme im Laufe der Zeit anhäufen.
Veröffentlichen der Build-Artefakte
Das Endprodukt eines automatisierten Buildprozesses sind Build-Artefakte, die Installationsprogramme, WAR-Dateien, Bibliotheken und Container umfassen können. Indem Sie diese Dateien in einem Artefakt-Repository veröffentlichen, können Sie von einem zentralen Speicherort aus Builds für verschiedene Umgebungen bereitstellen, idealerweise mithilfe von Deployment-Tools.
Nach dem Buildvorgang folgen als nächste Stufe der CI/CD-Pipeline normalerweise automatisierte Funktionstests, zu deren Durchführung der Build in einer oder mehreren Testumgebungen bereitgestellt werden muss (manchmal zusammen mit anderen Komponenten wie einer Datenbank oder anderen Microservices). Wenn diese Tests erfolgreich abgeschlossen wurden, kann der Build zur Aktualisierung von Staging-Umgebungen verwendet und schließlich für den Produktionsbetrieb freigegeben werden.
Kennzahlen und Feedback
In Ihrem CI-Tool können Sie sich die Ergebnisse der Build-Phase anzeigen lassen. Dazu gehört die Information, ob der Build erfolgreich erstellt wurde, sowie die Ergebnisse von Unit-Tests und anderen Prüfungen. Wenn Sie Warnungen konfigurieren, die Sie über Fehler benachrichtigen, können Sie schnell reagieren, um Ihren Code wieder in einen releasefähigen Zustand zu versetzen.
Ein Deployment-Tool sammelt außerdem Daten aus Ihrer Pipeline, damit Sie Trends erkennen können. Indem Sie den Buildverlauf und Kennzahlen wie Builddauer, Erfolgsraten und Codeabdeckung überprüfen, können Sie Erkenntnisse gewinnen, auf deren Grundlage sich Ihr CI/CD-Prozess optimieren lässt.
Fazit
Die Automatisierung Ihrer Builds gehört zu den wichtigsten ersten Schritten beim Einrichten Ihrer CI/CD-Pipeline und des gesamten Build-Managements. In dieser Hinsicht empfiehlt sich der Einsatz geeigneter Deployment-Tools. Die Build-Phase bietet eine erste, schnelle Feedback-Runde und bildet die Grundlage für die nachfolgenden Phasen der Pipeline, von automatisierten Tests bis hin zu Continuous Delivery und Continuous Deployment.