Azure DevOps allgemeine Release Pipeline erstellen
Im letzten Beitrag habe ich gezeigt wie man in Azure DevOps eine Release Pipeline für eine Web-Applikation auf einem IIS Server erstellt. Nun zeige ich, wie man eine allgemeine Release Pipeline erstellt in der eine Software auf einen Server kopiert wird.
Azure DevOps allgemeine Release Pipeline erstellen
Azure DevOps stellt viele fertig konfigurierte Pipelines zur Verfügung die man nur noch um konkrete Konfigurationswerte anreichern muss. Trotz der Vielfalt gibt es für nicht für jede denkbare Konstellation das richtige Template. Das ist auch gar nicht tragisch, da man jedes Template erweitern kann und für Spezialfälle immer auf die PowerShell ausweichen kann. Die PowerShell läuft auf jedem Zielsystem (siehe dazu die Dokumentation), weshalb man im allgemeinsten Fall jede Release Prozedur in einem oder mehreren PowerShell Skripten abbilden kann. Und das geht so…
PowerShell Release Pipeline
Für meine PowerShell Pipeline verwende ich das „Run PowerShell on Target Machines“ Template, dass im Prinzip leer ist und nur die Möglichkeit bietet ein PowerShell Script in das TextArea Steuerelement zu kopieren. In meinem Fall beende ich am Server einfach einen laufenden Prozess mit dem Befehl:
Stop-Process-Name "PROZESSNAME" -Force
danach kopiere ich mit beliebig vielen weiteren Steps die in der Build Pipeline erstellten Artefakte. Dazu eignen sich die „Windows machine file copy“ Templates in der man einfach angibt welches Artefakt an welchen Absoluten Pfad am Server kopiert werden soll.
Testen
Wie schon bei der Build Pipeline muss man die Release Pipeline auf Funktionalität prüfen. Das geht am besten mit einem Test-Deploy. Wie ich bereits gezeigt habe kann man beliebige Deploy Targets erstellen und mit Tags ansprechen. Aus den Logs im Azure DevOps erkennt man sofort, ob alles Steps erfolgreich waren. In meinem Fall musste am Zielsystem noch die Ausführung von Remote PowerShell Skripts zugelassen werden. Das funktioniert mit dem Befehl
enable-psremoting
überprüfen kann man den aktuellen Status mit
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell
in beiden Fällen benötigt man am Zielsystem die jeweiligen Rechte.
Was ist alles möglich?
Die Frage ist einfach zu beantworten: alles was man auch über PowerShell machen kann. Im schlimmsten Fall muss man recht komplexe PowerShell Skripte schreiben und diese remote ausführen. Das kann bei neuen Sachen schon recht mühsam werden, bis man das Skript fertig getestet erstellt hat. Einfacher ist es vorgefertigte Templates zu verwenden und nur wenn davon gar nichts passt ein neues Skript erstellen. In meinem Fall war für den Kopiervorgang bereits ein fertiges Template verfügbar:
Dort gibt man neben Source (Quelle) und Destination Folder (Ziel) auch noch den Namen des Zielsystems (siehe dazu Deployment Groups) und den Admin Login samt Passwort an.
Fazit
Jede denkbare allgemeine Release Pipeline ist mit den verfügbaren Templates und PowerShell Skripts erstellbar. Das Betriebssystem am Zielsystem ist nicht relevant, die Microsoft Technologien (PowerShell) funktionieren mittlerweile überall. Mit der maximalen Flexibilität lassen sich beliebige Release Pipelines erstellen die im schlimmsten Fall sogar laufende Prozesse beenden und neue Prozesse starten können.
