Continuous Delivery mit Azure DevOps, Teil 3: Ausrollen per Geisterhand
Im dritten und letzten Teil dieser Artikelserie werden Backend und Client nochmals genau überprüft und dann ausgerollt – zunächst auf ein Staging-System und dann sogar in die Produktion.
- Dr. Holger Schwichtenberg
Eine Release-Pipeline in Azure DevOps bezieht sich auf Quellartefakte. Meist wird dies das Zip-Ergebnis einer Azure-Build-Pipeline sein, wie sie im zweiten Teil der Artikelreihe entstanden ist. Alternativ dazu kann eine Release-Pipeline auch Quellcode (aus Azure-DevOps-Repositories oder GitHub) oder Container (aus Docker Hub oder der Azure Container Registry) und sogar Resultate aus einem Jenkins-Server beziehen. Auf die Quellartefakte folgen mehrere sogenannte Stages.
Im Fall des Miracle-List-Backends soll es eine Staging- und eine Produktionsumgebung geben mit zehn beziehungsweise elf Schritten. Dabei soll dem Deployment in die Produktion bewusst noch eine manuelle menschliche Bestätigung vorgeschaltet sein. Das sieht man an dem Pfeil des Mensch-Symbols bei der Stage "Produktion" in Abbildung 1. Ein weiteres kleines Häkchen sieht man rechts oben am Quellartefakt. Das ist der "Continuous Deployment Trigger", der dafür sorgt, dass jedes Mal nach einem erfolgreichen Build-Prozess die Release-Pipeline losläuft.
Deployment nach Azure
Genau wie bei den Build-Pipelines gibt es für die Release-Pipelines Vorlagen. Die meisten beziehen sich auf ein Deployment in die Azure-Cloud. In diesem Beitrag soll das Deployment in eine SQL-Azure-Datenbank und einen Azure Web App Service erfolgen. Diese Ressourcen legt man über das Azure Web Portal mit vielen Mausklicks oder mit einem Skriptwerkzeug wie PowerShell an. Für ASP.NET-Core-Anwendungen ist wichtig, in den Azure App Services die Umgebungsvariable ASPNETCORE_ENVIRONMENT entsprechend dem Verwendungszweck auf "Staging" oder "Production" zu setzen.
Continuous Delivery mit Azure DevOps – die Serie
- Teil 1: Projektinstallation
- Teil 2: Bauen auf dem Server
- Teil 3: Ausrollen per Geisterhand
Auch wenn das Kompilat mit Azure DevOps bereits in der Cloud ist, sind die verschiedenen Azure-Dienste dennoch voneinander abgeschirmt. Der erste Schritt ist daher, Azure DevOps den Zugriff auf die angelegten Azure-Ressourcen zu erlauben. Das erfolgt in den Projekteinstellungen unter Pipelines | Service Connections. Hier ist eine "Azure Ressource Manager Connection" einzurichten unter Angabe der Azure Subscription und der gewünschten Ressource Group. Installieren kann die Verbindung nur ein Microsoft-Kontoinhaber, der die Rechte auf die entsprechende Azure Ressource Group hat. Die Releases konfigurieren und anstoßen können dann alle Benutzer des Azure-DevOps-Webportals, die zur Gruppe "Release Administrators" oder "Project Administrators" (siehe Project Settings | General | Security) gehören.
Auf Basis dieser Vorarbeiten wählt man dann die Vorlage "Azure App Service Deployment". Es entsteht eine erste Stage mit einem Task vom Typ "Azure App Service Deploy". Auf der Ebene der Stage einzustellen sind dann die erstellte Service Connection (bei "Azure Subscription", s. Abb. 2) und der Name des Web App Service. Zudem ist als Ausgangsartefakt der Build-Prozess "MiracleListBackend-CI" aus dem zweiten Teil der Artikelserie zu wählen. Das reicht bereits aus, um ein Release zu erstellen. Die Schaltfläche heißt hier nicht "Queue" wie bei den Build-Pipelines, sondern "Release". Wie auch bei den Build-Pipelines lässt sich der Ablauf über "Logs" schon während des Durchlaufs einsehen.
