Automatisierte Tests und die Continuous Delivery-Pipeline

Abgeschlossen

Sie kennen sich nun mit Continuous Deployment und der Bereitstellung von Software und Diensten aus. Doch es fehlt noch ein dritter Teil dieser Einheit. DevOps-Methoden umfassen die drei Elemente Continuous Integration, Continuous Deployment und Continuous Delivery.

In dieser Einheit erfahren Sie nun mehr über die erste der drei Komponenten: die Integration. Sie ist Teil des Entwicklungsprozesses, der noch vor der Bereitstellung stattfindet. Die von DevOps empfohlene Entwicklungsmethode sieht vor, dass die Teammitglieder regelmäßig Code in ein freigegebenes Repository integrieren, das eine einzelne Stamm- oder Hauptcodebasis enthält. Das Ziel soll sein, dass jeder seinen Teil zum später bereitgestellten Code beiträgt, anstatt einzeln und unabhängig voneinander am Code zu arbeiten, der dann in letzter Minute zusammengefügt wird.

Automatisierte Tests können dann die Integration jedes Teammitglieds überprüfen. Dadurch kann festgestellt werden, ob der Code nach einer Änderung oder einer Ergänzung noch fehlerfrei funktioniert. Diese Tests sind Teil der sogenannten Pipeline. Im folgenden Abschnitt erhalten Sie Informationen zur Continuous Delivery-Pipeline und zu Azure Pipelines.

Die Continuous Delivery-Pipeline

Damit Sie die Rolle automatisierter Tests im Continuous Delivery-Bereitstellungsmodell einordnen können, sehen Sie sich deren Position in der Pipeline an. Eine Continuous Delivery-Pipeline stellt die Implementierung der Schritte dar, die der Code beim Hinzufügen von Änderungen im Entwicklungsprozess vor der Bereitstellung in der Produktion durchläuft. In der folgenden Abbildung sehen Sie eine vereinfachte Darstellung einer Continuous Delivery-Pipeline mit Beispielschritten:

Diagramm mit acht Phasen einer Pipeline, von denen fünf Teil der Integration und drei Teil der Bereitstellung sind – die beiden roten Pfeile markieren die Test- und die Überprüfungsphase

Die Pipeline umfasst die folgenden Phasen:

  • Durch Committen von Code- oder Infrastrukturänderungen in einem Coderepository, etwa über einen Pull Request, wird eine Instanz der Pipeline gestartet.

  • Anschließend werden Komponententests, beispielsweise Integrations- oder End-to-End-Tests, durchgeführt, deren Ergebnisse im Idealfall an die anfordernde Stelle zurückgegeben werden.

  • An diesem Punkt wird der Code im Repository beispielsweise auf Geheimnisse, Sicherheitsrisiken und Konfigurationsaspekte überprüft.

  • Nach der Überprüfung wird der Code erstellt und für die Bereitstellung vorbereitet.

  • Im nächsten Schritt wird der Code in einer Testumgebung bereitgestellt. Ein Mitarbeiter kann über die neue Bereitstellung benachrichtigt werden, um einen Blick auf die Lösung in der Präproduktionsphase zu werfen. Er kann die Zustimmung zur Bereitstellung des Codes in der Produktion erteilen oder verweigern. Anschließend beginnt die letzte Phase des Bereitstellungsprozesses mit der Freigabe des Codes für die Produktion.

Bei dieser Pipeline wird die Einteilung in die Abschnitte „Integration“ und „Bereitstellung“ deutlich. Die roten Pfeile markieren zwei Stellen, an denen die Pipeline durch integrierte Logik und Automatisierungen, möglicherweise auch durch menschliches Eingreifen, unterbrochen werden kann.

Continuous Integration- und Continuous Delivery-Tools: Azure Pipelines

Damit Sie Continuous Integration und Continuous Delivery auch nutzen können, benötigen Sie die richtigen Tools. Azure Pipelines gehört zu Azure DevOps Services, mit dem Sie das Erstellen und konsistente Testen Ihres Codes automatisieren können. Mit Azure Pipelines können Sie den Code auch in Azure-Diensten, virtuellen Computern und anderen lokalen oder Cloudzielen bereitstellen.

Die Eingabe für eine Pipeline (Code oder Konfigurationen) befindet sich in einem Versionskontrollsystem wie GitHub oder einem anderen Git-Anbieter.

Wird Azure Pipelines auf einem Server, wie etwa einem virtuellen Computer oder einem Container, ausgeführt, werden Build-Agents für Windows, Linux und macOS bereitgestellt. Zudem bietet Azure Pipelines die Möglichkeit zur Integration mit Plug-Ins für Tests, Sicherheitsfunktionen und Codequalität. Und nicht zuletzt ist Azure Pipelines leicht erweiterbar, wodurch Sie eigene Automatisierungen ergänzen können.

Pipelines werden mithilfe der YAML-Syntax oder über die klassische Benutzeroberfläche im Azure-Portal definiert. Wenn Sie eine YAML-Datei verwenden, können Sie diese zusammen mit dem Code speichern. Pipelines enthalten außerdem Vorlagen, die Ihnen beim Erstellen einer Pipeline helfen, wie etwa einer Pipeline zum Erstellen eines Docker-Images oder eines Node.js-Projekts. Sie können eine vorhandene YAML-Datei auch wiederverwenden.

Unabhängig davon, ob Sie eine YAML-Datei oder die klassische Benutzeroberfläche verwenden möchten, führen Sie zum Erstellen einer Pipeline die folgenden grundlegenden Schritte aus:

  1. Konfigurieren Sie Azure Pipelines für die Verwendung Ihres Git-Repositorys.
  2. Definieren Sie den Build, entweder durch Bearbeiten der Datei azure-pipelines.yml oder über den klassischen Editor.
  3. Übertragen Sie den Code per Push in Ihr Repository für die Versionskontrolle. Durch diese Aktion beginnt die Pipeline mit dem Erstellen und Testen des Codes.

Nachdem der Code aktualisiert, erstellt und getestet wurde, können Sie ihn an dem von Ihnen gewünschten Ziel bereitstellen.

Einige Funktionen sind nur bei Verwendung der YAML-Syntax verfügbar (wie das Ausführen von Containeraufträgen), andere nur über die klassische Benutzeroberfläche (wie etwa Aufgabengruppen).

Aufbau einer Azure-Pipeline

Pipelines sind gegliedert in:

  • Aufträge: Ein Auftrag ist eine Gruppe von Aufgaben oder Schritten, die auf einem einzelnen Build-Agent ausgeführt werden. Ein Auftrag ist die kleinste Arbeitseinheit, deren Ausführung Sie planen können. Die einzelnen Schritte eines Auftrags werden nacheinander ausgeführt. Bei den Schritten kann es sich um jede Art von gewünschter Aktion handeln, wie etwa das Erstellen/Kompilieren von Software, das Vorbereiten von Daten für Tests, das Ausführen bestimmter Tests usw.

  • Phasen: Eine Phase ist eine logische Gruppierung miteinander verknüpfter Aufträge.

Jede Pipeline verfügt über mindestens eine Phase. Mit mehreren Phasen können Sie die Pipeline in größere Abschnitte einteilen und die Stellen markieren, an denen sie für die Durchführung von Überprüfungen angehalten werden kann.

Pipelines können Ihren Anforderungen entsprechend einfach oder komplex aufgebaut sein. Sehr gute Tutorials zur Erstellung und Verwendung von Pipelines finden Sie im Lernpfad Erstellen von Anwendungen mit Azure DevOps.

Nachverfolgbarkeit von Umgebungen

Ein weiterer Aspekt zur Zuverlässigkeit von Pipelines sollte noch erwähnt werden. Sie können Ihre Pipeline so erstellen, dass Sie die jeweilige Ausführung in der Produktion einer bestimmten Buildinstanz zuordnen können. Im Idealfall sollte es somit möglich sein, einen Build zu einem bestimmten Pull Request oder einer Codeänderung zurückzuverfolgen. Dies kann sich als äußerst nützlich erweisen, sollte ein Incident auftreten oder wenn Sie nach Auftreten eines Incidents die Änderung identifizieren möchten, die das Problem verursacht hat. Bei einigen Continuous Integration-/Continuous Delivery-Systemen (wie Azure Pipelines) ist dies ganz einfach, während Sie bei anderen Systemen die Pipeline manuell so erstellen müssen, dass alle Phasen eine Art Build-ID enthalten.

Überprüfen Sie Ihr Wissen

1.

Welches der folgenden Elemente umfasst üblicherweise die Schritte „Committen“, „Testen“, „Überprüfen“ und „Erstellen“?

2.

Die Nachverfolgbarkeit von Umgebungen ermöglicht welche der folgenden Aktionen?