Automatisierung von Tests und die Bereitstellungspipeline

Sie haben über Continuous Deployment und die Lieferung von Software und Diensten gelernt, aber die beiden sind eigentlich Teile einer Triade. DevOps-Methoden zielen darauf ab, kontinuierliche Integration, Bereitstellung und Auslieferung zu erreichen. Diese Praktiken werden in der Regel in dieser Reihenfolge aufgebaut, wobei jede von der jeweiligen vor ihnen abhängt.

Jetzt ist es an der Zeit, zurückzutreten und den ersten dieser Punkte zu besprechen: 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 ist es, dass jeder zu dem Code beiträgt, der später bereitgestellt wird, anstatt an einer eigenen Kopie zu arbeiten und dann erst in letzter Minute alles zusammenzuführen.

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. Das Testen ist Teil der häufig als Pipeline bezeichneten Pipeline. Der rest dieser Einheit konzentriert sich auf integrierte Test- und Lieferpipelinen.

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 Grafik sehen Sie eine vereinfachte Darstellung einer Lieferpipeline mit Beispielschritten:

Gehen Sie schritt für Schritt durch diese Pipeline:

• Eine Instanz der Pipeline wird gestartet, wenn Code- oder Infrastrukturänderungen in ein Code-Repository eingepflegt werden, etwa über einen Pull-Request.

• Als Nächstes werden Komponententests ausgeführt, häufig gefolgt von Integrations- oder End-to-End-Tests. Die Ergebnisse werden dem Entwickler mitgeteilt, der die Pullanforderung geöffnet hat.

• In dieser Phase wird der Code im Repository häufig auf Geheimschlüssel, Sicherheitsrisiken und Fehlkonfigurationen ü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 Prüfer kann über die neue Bereitstellung benachrichtigt werden, damit sie die Preproduction-Lösung untersuchen können. Der Prüfer genehmigt oder verweigert dann die Förderung in die Produktion, wodurch der letzte Teil des Bereitstellungsprozesses gestartet wird, der den Code in die Produktion freigibt.

Bei dieser Pipeline wird die Einteilung in die Abschnitte „Integration“ und „Bereitstellung“ deutlich. Die hervorgehobenen Markierungen verweisen auf einige logische Stellen, an denen Sie die Pipeline durch eingeschlossene Logik und Automatisierung oder potenziell sogar menschliche Eingriffe beenden können.

Tools für kontinuierliche Integration und Bereitstellung: Azure Pipelines und GitHub Actions

Damit Sie Continuous Integration und Continuous Delivery auch nutzen können, benötigen Sie die richtigen Tools. Microsoft bietet zwei CI/CD-Optionen von Erstanbietern zum Erstellen und Bereitstellen in Azure: Azure Pipelines (Teil der Azure DevOps) und GitHub Actions. Beide können das Erstellen und durchgängige Testen Ihres Codes automatisieren und sowohl zu Azure-Diensten, virtuellen Maschinen als auch zu anderen Zielen in der Cloud und vor Ort bereitstellen. Viele Teams übernehmen GitHub Actions, wenn sich ihr Quellcode bereits in GitHub befindet, während Azure Pipelines eine starke Wahl für Teams bleibt, die auf Azure DevOps standardisiert sind.

Der Rest dieser Einheit konzentriert sich auf Azure Pipelines, aber GitHub Actions verwendet ähnliche allgemeine Ideen, obwohl sich die Terminologie unterscheidet. In GitHub Actions enthalten Workflows Jobs und Schritte, Aktionen bieten wiederverwendbare Automatisierungen, Runner führen die Arbeit aus, und Umgebungen können Bereitstellungen schützen.

Die Eingabe an eine Pipeline (Code oder Konfigurationen) befindet sich in einem Versionssteuerungssystem wie GitHub oder einem anderen Git-Anbieter.

Azure Pipelines läuft auf Rechenressourcen wie einem virtuellen Computer oder einem Container und bietet von Microsoft gehostete Build-Agents, die unter Windows, Linux und macOS laufen. Sie können Ihre eigenen selbst gehosteten Agents auch registrieren, wenn Sie die vollständige Kontrolle über die Build-Umgebung benötigen. Sie bietet auch Integration in Test-, Sicherheits- und Codequalitäts-Plug-Ins. Schließlich ist es einfach erweiterbar, sodass Sie Ihre eigene Automatisierung in Azure Pipelines bringen können.

Pipelines werden mithilfe der YAML-Syntax definiert, die zusammen mit Ihrem Code in einem Git-Repository gespeichert ist. YAML-Pipelines sind der empfohlene Ansatz für neue Projekte. Eine klassische Benutzeroberfläche in Azure DevOps ist auch für Legacy-Pipelines verfügbar, aber die meisten neuen Funktionen (einschließlich Containeraufträgen und vieler erweiterter Funktionen) sind nur in YAML verfügbar. Pipelines stellen auch Vorlagen bereit, mit denen Sie problemlos Pipelines erstellen können, z. B. eine Vorlage für ein Docker-Image oder ein Node.js Projekt. Sie können eine vorhandene YAML-Datei auch wiederverwenden.

Die grundlegenden Schritte zum Einrichten einer Pipeline sind:

1. Konfigurieren Sie Azure Pipelines für die Verwendung Ihres Git-Repositorys.
2. Definieren Sie Ihren Build, indem Sie die azure-pipelines.yml-Datei bearbeiten (oder für Legacypipelinen mithilfe des klassischen Editors).
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.

Azure Pipeline-Erstellung

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 diesen Schritten kann es sich um jede benötigte Aktion handeln, einschließlich Erstellung oder Kompilierung von Software, Vorbereiten von Beispieldaten für Tests, 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. Lernprogramme zur Konstruktion 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 sollten Sie in der Lage sein, einen Build auf eine bestimmte Pullanforderung oder Codeänderung zurückzuverfolgen. Diese Rückverfolgbarkeit ist während eines Vorfalls von unschätzbarem Wert und danach während der Überprüfung nach dem Vorfall, wenn Sie versuchen, zu identifizieren, welche Änderung zu einem Problem beigetragen hat. Einige CI/CD-Systeme (z. B. Azure Pipelines und GitHub Actions) machen diese Korrelation unkompliziert, während andere sie benötigen, um manuell eine Pipeline zu erstellen, die eine Build-ID über jede Phase verteilt.