Praktische Umsetzung von DevOps Schritt für Schritt

Im Zeitalter schneller Releases und kontinuierlicher Betriebszeiten für Softwareanwendungen sind die meisten von Ihnen mit den Vorteilen von DevOps für eine integrierte Entwicklung und Bereitstellung vertraut. In diesem Beitrag wird ein schrittweiser Prozess detailliert beschrieben, der die praktische Umsetzung von DevOps mit einer automatisierten Build-Integrate-Test-Release-Pipeline veranschaulicht.

Wesentliche Elemente von DevOps

Unabhängig von den von Ihnen verwendeten Tools und dem zugrunde liegenden Technologie-Stack gibt es ein paar wesentliche Elemente für eine erfolgreiche DevOps-Umgebung, nämlich:

• • Code-Repository mit Versionskontrolle
  • Kontinuierliche Integration (CI)
  • Automatisiertes Bauen
  • Automatisierte Freigabe durch Continuous Delivery oder Continuous Deployment (CD)

Im Falle einer manuellen Bereitstellung sieht der CI/CD-Workflow von Code Commit<Continuous Integration<Continuous Delivery wie in der Abbildung unten dargestellt aus:

Der Hauptunterschied zwischen Continuous Delivery und Continuous Deployment besteht darin, dass bei ersterem die Übergabe des Codes an die Produktion manuell erfolgt, während sie bei letzterem Szenario automatisiert ist.

Für einen Kunden, dessen Anwendung auf einem Microsoft-Technologie-Stack basiert und mit Azure-Cloud-Services bereitgestellt wird, haben wir die Build-to-Release-Pipeline wie unten beschrieben automatisiert:

Code Commit und Versionskontrolle

Mit Git als Code-Repository haben wir den folgenden Prozess für das Commit des Codes und das Auslösen eines Pre-Builds übernommen:

• Erstellen Sie eine Pull-Anfrage, um nach regelmäßigen Aktualisierungen von einzelnen Entwicklern zu suchen und den Code mit der entsprechenden Versionierung an das Code-Repository zu übergeben. Git erzeugt eine dynamische Versionsnummer, die auf den Zweigen und den Änderungen basiert, die vor dem aktuellen Build übertragen wurden
• Mithilfe von NuGet, einem Microsoft-spezifischen Tool zur Identifizierung und Zusammenführung aller abhängigen Codes, wird ein NuGet-Paket generiert. Dabei handelt es sich um eine einzelne ZIP-Datei mit der Erweiterung .nupkg, die kompilierten Code (DLLs), andere mit diesem Code zusammenhängende Dateien und ein beschreibendes Manifest mit Versionsnummer und Datums-/Zeitstempel enthält.
• Jeder neue Code-Commit löst einen automatischen Pre-Build aus, um die Unantastbarkeit des eingecheckten Codes zu überprüfen.
• Im Rahmen des Pre-Builds werden die betroffenen Tests (Unit-Tests) automatisch ausgeführt.
• Wenn der Pre-Build nicht erfolgreich ist, wird eine automatische Benachrichtigung über den fehlgeschlagenen Build generiert.

Kontinuierliche Integration

Continuous Integration (CI) ist eine Entwicklungsmethode, die den von mehreren Entwicklern erstellten Code über ein automatisiertes Framework integriert. Wir haben Microsoft Visual Studio Team Services (VSTS) als CI/CD-Tool verwendet und den folgenden Prozess übernommen:

• Wenn der Pre-Build erfolgreich ist, wird eine automatische Merge-Anfrage generiert.

• Die Merge-Anforderung löst einen neuen Build aus, der die Lösung erstellt und mit dem Master-Zweig zusammenführt.

• Automatisierte Regressionstests werden in der Lösung ausgeführt. Die Aufgabe Visual Studio Test führt automatisch Tests aus, die in den App-Assemblies enthalten sind. Es gibt jedoch eine Vielzahl von Konfigurationsoptionen, mit denen Sie nur bestimmte Tests ausführen können. Siehe Tests mit der Visual Studio Aufgabe ausführen für weitere Informationen.
• Wenn die Regressionstests nicht erfolgreich sind, wird eine automatische Fehlermeldung erzeugt.

Release Management: Bereitstellung und Auslieferung

Quelle: Microsoft

Continuous Deployment (CD) ist die Fähigkeit, den Output von CI zu nutzen und den getesteten Build automatisch in verschiedenen Umgebungen einzusetzen. Bei der kontinuierlichen Bereitstellung müssen Sie manuell entscheiden, ob der Build in die Staging- oder Produktionsumgebung übertragen werden soll, während bei der kontinuierlichen Bereitstellung die neueste Arbeitsversion automatisch in die Produktionsumgebung übertragen wird.

• Wenn die Regressionstests erfolgreich sind, wird ein Artefakt in den Release-Zweig verschoben.

• Im Falle einer kontinuierlichen Lieferung wird eine Benachrichtigung erstellt und an einen Genehmiger gesendet.
• Der Genehmiger löst die Bereitstellung der Anwendung in einer Staging-Umgebung manuell aus, indem er die Azure Cloud Services-Bereitstellungsaufgabe verwendet.
• Hier werden manuelle Funktionstests durchgeführt, und wenn sie erfolgreich sind, wird die Anwendung in der Produktionsumgebung eingesetzt. Wenn die Funktionstests automatisiert sind, führen Sie sie früh in der CD-Pipeline durch. Fügen Sie dazu den Deploy Test Agent und Run Functional Tests zu Ihrer Release-Definition hinzu. Siehe Testen in Continuous Integration und Continuous Deployment Workflows für weitere Informationen
• In der Produktionsumgebung werden Leistungs- und Verfügbarkeitstests manuell durchgeführt, bevor die Anwendung für die Live-Umgebung freigegeben wird. Lasttests können durchgeführt werden mit Cloud-basierte Lasttests und Apache JMeter-Lasttests durchgeführt werden.

• Die Azure PowerShell-Aufgabe wird verwendet, um die Anwendung von der Staging- in die Produktionsumgebung zu verschieben. Sobald die Anwendung in Betrieb ist, wird die Staging-Instanz ausgesetzt.
• Im Falle von Änderungen am Datenbankschema wird dieses durch die Aufgabe Azure SQL ausführen aktualisiert.

• In einer kontinuierlichen Bereitstellungsumgebung werden alle oben genannten Aufgaben, einschließlich Funktions-, Leistungs- und Verfügbarkeitstests, ebenfalls automatisiert, und die Anwendung wird ohne manuelles Eingreifen in einer Live-Umgebung bereitgestellt.
• White Source Bolt und White Source-Erweiterungen, die in VSTS verfügbar sind, werden verwendet, um auf externe Abhängigkeiten zu prüfen und sicherzustellen, dass das Paket in jeder Hinsicht vollständig und auf dem neuesten Stand ist. Dies ist ein obligatorischer Schritt, der als Teil der Build & Release Pipeline ausgeführt wird.

Der Umschlag

Der Grad der Automatisierung, für den man sich im Rahmen von DevOps entscheidet, hängt weitgehend von der Art der Entwicklungsumgebung sowie von den Anforderungen der Produktions- und/oder Live-Umgebung ab. Die richtigen Tools und Arbeitsabläufe tragen wesentlich dazu bei, dass der neueste Code stets produktionsbereit und einsatzfähig ist.

Der Autor ist Senior Software Engineer im Vision Planner-coMakeIT-Team.

[contact-form-7 id="20990" title="DevOps für kontinuierliche Innovation"]