Azure DevOps Release Pipeline erstellen

In diesem Tutorial zeige ich wie man in Azure DevOps eine Release Pipeline erstellen kann. Damit lassen sich über DevOps automatisch gebaute Artefakte auch gleich auf das Zielsystem übertragen. Damit ist auch der letzte Bereich hin zum Produktivsystem automatisiert.

Azure DevOps Release Pipeline erstellen

Genau genommen zeige ich in den folgenden Absätzen wie man sich eine Release Pipeline zusammenstellt, die das zuvor gebaute Projekt auf einem On-Premise Server bereitstellt. Damit das funktioniert muss dieser Server (das Ziel) bereits im Azure DevOps bekannt sein und einer Deployment Gruppe hinzugefügt worden sein. In meinem Server einer Deployment Gruppe hinzufügen Artikel beschreibe ich alles nötige und gehe nun davon aus, dass DevOps auch bei dir ein ähnliches Bild zeigt:

Eine Deployment Gruppe mit einem Server.

Pipeline erstellen

Im Menü findet sich unter Pipelines der Punkt Releases. Dort können beliebig viele Release Pipelines erstellt werden. Will man nun eine neue Pipe erstellen zeigt DevOps eine Übersicht aller verfügbaren Templates. Für die meisten Aufgaben findet man schon recht gute vordefinierte Bausteine die man nur noch konfigurieren muss.

Ich möchte Beispielsweise meine ASP.NET App direkt für einen auf einem Windows Server laufenden IIS Webserver veröffentlichen. Ein passendes Template dazu ist IIS Website Deployment. In der Übersicht zur Pipeline werden 2 Bereiche dargestellt:

• Artifacts
  Was soll released werden? Dort müssen wir die zuvor in der Build Pipeline erstellten Artefakte einstellen.
• Stages
  Wo/Wie soll released werden? Neben dem Ziel definiert man im Stage auch wie die Artefakte am Zielsystem landen.

Diese Übersicht ist eine minimale Release Pipeline. Diese kann beliebig durch weitere Artefakte und Stages erweitert werden. Ich denke da beispiel an das übliche Setup mit Dev-, Test- und Live-Server.

Artifacts konfigurieren

Mit einem Klick auf „Add an artifact“ öffnet sich ein Detailbereich in dem man wieder unterschiedliche Optionen für die Herkunft der Artefakte hat. Ich wähle Build, da ich den Code des Git Repos auf Azure DevOps zuvor in einer Build Pipeline gebaut habe. Unter Angabe vom Projekt, der Build Pipeline der gewünschten Version und der Quelle des gespeicherten Artefakts ist die Konfiguration auch schon fertig. Details ob das so korrekt ist oder Änderung bedarfs bekommt man über das Log der ersten Ausführung.

Stage konfigurieren

Als nächstes muss man die Logik erstellen wie und wohin das Artefakt kopiert werden soll. Der Kreativität sind dort keine Grenzen gesetzt, da mit einem PowerShell Script man nahezu alles machen kann. Einfacher ist es aber mit den vordefinierten Templates zu arbeiten. Im Fall des IIS Deployments besteht das Template aus 2 Schritten:

In meinem Fall habe ich den Stage 1 gleich in „Test“ umbenannt. In der oberster Konfigurationsebene wählt man den „Configuration type“, der meist eine IIS Website oder eine IIS Web Application sein wird. Als „Website name“ gibt man den Namen der im IIS auf dem Webserver eingestellten Namen ein und bei „Virtual path“ den relativen Verzeichnisnamen.

Spannend wird die Konfiguration beim „IIS Deployment“ Punkt. Dort gibt man unter „Deployment group“ die zuvor angelegte Deployment Gruppe mit dem registrierten On-Premise Server an. Da man dort neben Test-, Dev- auch Produktivsysteme registriert, kann das Ziel beispielsweise über „Required tags“ spezifiziert werden. Wurde der Testserver mit dem Tag „test“ versehen und du gibst nun im Stage „test“ an, dann wird nur auf diesem Server deployed.

Als nächstes folgen die einzelnen Schritte die ausgeführt werden. Meist reichen die Steps Manage und Deploy vom Blueprint. Unter Manage wird geprüft ob der Webseitenname, der virtuelle Pfad und der physische Pfad existieren. Im Deploy Schritt wird dann am angegebenen Ort das gepackte Artefakt entpackt.

Sollte man zusätzliche Tasks ausführen müssen, so lassen sich weitere Schritte hinzufügen. Sofern es kein passendes Template gibt bleibt immer noch die Konsole. So lässt sich beispielsweise mit einem PowerShell Skript ein laufender Prozess vor dem Deployen abbrechen und nach dem Prozess wieder neu starten.

Testen

Niemand erstellt einfach so mal eine Release Pipeline die sofort funktioniert. Bis der Automatismus Wartungsfrei läuft sind nun noch einige Iterationen nötig. Dazu startet man am besten auf einem Testsystem und lässt für dort die Pipeline laufen. Azure DevOps zeigt folgenden Screen:

Mit einem Klick auf das laufende Deployment kann man sich die Logs in Echtzeit im Detail ansehen.  Das Debuggen ist so recht einfach, Fehler werden schnell identifiziert und nach einer kurzen Anpassung der Konfiguration läuft auch schon der nächste Run. Hat man nach ein dutzend Versuchen dann die korrekte Kombination aus Pfaden und Namen gefunden braucht man sich keine Gedanken mehr über das korrekte Deployment auf einen Server machen. Läuft dieser Automatismus mehrere Wochen fehlerfrei am Dev- bzw. Testsystem, dann kann man beruhigt auch das Produktivsystem anschließen.

Fazit

Die Einarbeitung in die Azure DevOps Release Pipeline lohnt sich. Nach einem Nachmittag Umsetzung und einen weiteren Nachmittag für die Prüfung und Anbindung des Produktivsystems hat man eine stabile Deployment Pipeline eingerichtet. Je nach Bedarf kann diese an sich ändernde Bedürfnisse angepasst werden und ist stets versioniert. Einmal Automatisiert steigt so der Releasezyklus neuer Funktionen und die Verteilung auf die Produktivsysteme macht keine Kopfschmerzen mehr.