Nachdem wir nun inzwischen ja automatisch über die VSTS unsere Anwendung “bauen” können, soll es nun darum gehen, diese Anwendung auch jemandem Zugänglich zu machen, damit er sich die Tolle Anwendung ansehen kann. Die Anwendung muss also deployed werden.
Für den Zweck habe ich in Azure bereits zwei Websites angelegt: eine für das Testing und eine für den Produktivbetrieb. Immer wenn wir einen neuen Build erstellt haben, soll dieser automatisch in der Testing-Umgebung eingespielt werden.
Hier kommt nun das neue Release-Management der Visual Studio Team Services ins Spiel. Unter “RELEASE” kann ich eine neue Release-Definition anlegen – ähnlich wie bei den Builds.
Auch hier Starte ich zunächst mit einem leeren Template.
Nun kann ich meine beiden Umgebungen Dev und Prod anlegen. Jede Umgebung verfügt über eigene Tasks, die beim Deployment ausgeführt werden sollen. In meinem Fall also eine “Azure Web App Deployment” Task.
Als Parameter der Task habe ich hier meine Azure-Subscription ausgewählt sowie die Website in die das Deployment stattfinden soll. Schließlich habe ich als Deploy-Package das ZIP-File angegeben, welches ich im Build zuvor gebaut habe.
Die Task im Prod-Environment sieht genauso aus – nur dass hier eine andere Website ausgewählt ist.
Bei den Artefakten kann ich auf meine Build-Definition verweisen – somit ist klar woher die Release-Definition weiß wo das ZIP zu finden ist.
Nun müssen jeweils noch die Environments konfiguriert werden.
Also Queue habe ich hier auch wieder meine Default-Queue verwendet, und bei den Deployment-conditions habe ich eingestellt, dass das Deployment nach jedem erfolgreichen Build gestartet werden soll.
Für die Produktiv-Umgebung sieht der Trigger etwas anders aus – hier wird das Deployment durch ein erfolgreiches vorhergehendes Deployment ausgelöst.´
Damit das Deployment nicht einfach so “durchrauscht” habe ich das Deployment in der Dev-Umgebung mit einem sogenannten Post-Deployment-Approver versehen. Das bedeutet, dass nach dem Deployment auf der Dev-Umgebung eine Aufgabe an einen Approver gesendet wird. Dieser kann das Deployment anschließend prüfen. Ist alles OK kann das deployment approved werden und es wird automatisch auch auf Prod eingespielt.
Eine kleinigkeit fehlt nun aber noch, damit aus dem Build direkt auch ein Deployment erfolgen kann. Wir haben zwar im Deployment den Namen unseres ZIP-Files aus dem Build-Prozess angegeben, und wir haben gesagt, dass wir die Artefakte aus unserer Build-Definition verwenden wollen, aber der Build stellt bisher noch keine Artefakte zur Verfügung. Da Build und Release ganz unabhängige Prozesse sind, können die nicht einfach so auf die Dateien des jeweils anderen zugreifen.
Also muss ich in der Build-Definition noch angeben, was ich denn als Artefakt bereitstellen will. Dazu füge ich meiner Build-Definition einen “Copy and Publish Build Artifacst” Step hinzu, in dem ich das ZIP-File als zu veröffentlichendes Artefakt angebe.
Wenn ich nun einen neuen Build anstoße, dann wird anschließend automatisch auch der Release-Prozess mit meinen beiden Deployments gestartet. In der Zusammenfassung des Build kann ich auch alle erfolgten Deployments sehen.
Und auch in der Übersicht der Releases sehe ich mein Release mit dem zugehörigen Build.
