Telefon-Nummer +49 (0)7304 / 803 0

BLOG-N-ROLL:
Wissen,
Das Rockt!

ALM

2018.04.26

Deployment Groups unter VSTS/TFS
By Thomas Trotzki / 26 April / ALM / 0 comm.

Mit Einführung von Release Pipelines wurde TFS schon vor geraumer Zeit in die Lage versetzt, auch das physikalische Rollout von Anwendungen zu verwalten. Zwischenzeitlich hat das Leistungsmerkmal Release Management auch schon eine durchaus nennenswerte Verbreitung gefunden. Wer unter TFS 2015 (ab Update 2) oder unter TFS 2017 schon einmal versucht hat, ein Rollout bis zur […]

Mit Einführung von Release Pipelines wurde TFS schon vor geraumer Zeit in die Lage versetzt, auch das physikalische Rollout von Anwendungen zu verwalten. Zwischenzeitlich hat das Leistungsmerkmal Release Management auch schon eine durchaus nennenswerte Verbreitung gefunden.

Wer unter TFS 2015 (ab Update 2) oder unter TFS 2017 schon einmal versucht hat, ein Rollout bis zur produktiven Umgebung hin zu automatisieren, der kennt das Leid: die produktive Umgebung ist „dicht“, für ein Deployment muss aber logischer weise ein Kanal geöffnet sein. Mögliche Kanäle sind vielfältig und von den meisten Verantwortlichen einer produktiven Umgebung durchaus nicht wirklich gerne gesehen. In der Regel führt dies zur Diskussion über „das kleinere Übel“: ist nun eine Netzwerkfreigabe auf dem Server, auf die die neue Version kopiert werden kann, das Richtige oder soll besser über IIS WebDeploy veröffentlich werden oder auch FTP. Und wie wird anschließend die Konfiguration der Anwendung vorgenommen, dies sollte ja ebenfalls stabil automatisiert werden.

blog-20180426-01

Herkömmliche Tasks, Ausführung auf dem Release Agent

  • Task: Copy Files: wird lokal auf dem Release Agent ausgeführt. Das Zielsystem muss eine Netzwerkfreigabe haben, um die Anwendung auf das System kopieren zu können
  • Task: PowerShell: PowerShell wir auf dem Release Agent ausgeführt
  • Task: Deploy IIS App: Hierfür müssen auf dem Zielsystem die IIS WebDeploy Dienste ausgeführt werden. Diese erlauben ein Kopieren der Dateien über „Web Deployment Agent Service“ (MsDepSvc:80), die Konfiguration erfolgt über „Web Management Service“ (WmSvc:8172)

Einen ersten Lösungsansatz hat Microsoft mit WinRM basierten Tasks bereits seit längerem im Leistungsangebot. WinRM vereinheitlicht zwar die Wege hin zum einem Zielsystem, über einen einzigen Port können sowohl Daten kopiert als auch „Remote Admin“ durchgeführt werden. Doch wer WinRM in der Praxis konfiguriert, sieht dies ebenfalls nur als „kleineres Übel“ an, muss doch ein eingehender Port auf dem System erlaubt werden. Und wer WinRM schon einmal über die Grenzen einer Windows-Domain hinweg konfigurieren durfte hat dabei sicherlich ein paar mehr Stunden als geplant damit zugebracht. Und nicht zu vergessen, Cross Platform tauglich ist dieses Modell sicherlich nicht.

image

WinRM Tasks, Ausführung auf dem Release Agent, die eigentliche Aktion wird aber Remote auf dem Zielsystem ausgeführt

  • Task: Windows Machine File Copy: Der Copy Befehl wird über WinRM an das Zeilsystem weitergegeben, die Dateien werden ebenfalls per WinRM auf das Zielsystem übertragen
  • Task: PowerShell on Remote Machines: Das PowerShell Skript wird per WinRM an das Zielsystem übertragen und dort ausgeführt
  • Task: WinRM – IIS Web App Deployment / Management: Hier wird die Kommunikation über WinRM ausgeführt, das eigentliche Konfigurieren läuft dann direkt auf dem Zielsystem ab.

image

Einsatz von Deployment Groups, es findet nur noch ausgehende Kommunikation statt, ports müssen auf den Zielmaschine nicht mehr veröffentlicht werden Deployment Groups, mit TFS 2018 eingeführt, addressieren genau dieses Problem. Im Grunde wird das gleiche Konzept, ja sogar das gleiche Software-Paket zum Einsatz gebracht, wie dies schon seit Jahren für Build und Release Pipelines erfolgreich in hybriden Umgebungen zum Einsatz kommt. Auf den Zielmaschinen werden „task based agents“ installiert und im Modus „deployment group“ konfiguriert. Läuft ein solcher Agent auf der Zeilmaschine, so nutzt er
das Pull Verfahren, um kontinuierlich beim TFS Application Tier nachzufragen, ob ein neuer Deployment Auftrag zu ihn vorliegt. Dieser wird dann wie auf einem Build und/oder Release Agent abgearbeitet. Der Vorteil dieses Vorgehens: Tasks werden im Kontext der Zielmaschine ausgeführt, die nochwendigen Artifacts werden automatisch vorab vom Release Agent auf die Zielmaschine repliziert. Somit laufen alle Kopier- und Konfigurationsschritte lokal ab und die produktive Zeilmaschine kann nach außen hin auch komplett dicht bleiben.

Unter VSTS bedeutet dieses Modell, dass nun die eigentlichen Release Agents ebenfalls problemlos Hosted genutzt werden können, die Zielmaschinen im firmeninternen Netz holen nun ihre Aufträge selbst von den
VSTS ab.

Aktuelles

Nach oben