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

BLOG-N-ROLL:
Wissen,
Das Rockt!

ALM

2016.01.28

Deployment einer ASP.NET Anwendung inkl. Datenbank nach Azure mit Visual Studio Release Management
By admin / 28 January / ALM / 0 comm.

Mit Hilfe von Visual Studio Team Services (VSTS) kann eine Web-Anwendung einfach gebaut und auf einen Server – in diesem Beispiel auf Azure – deployed werden. Auch der Team Foundation Server (TFS) wird dieselbe Funktionalität unterstützen, jedoch ist zum Zeitpunkt der Entstehung dieses Beitrags (Januar 2016) das neue Release Management im TFS noch nicht verfügbar. […]

Mit Hilfe von Visual Studio Team Services (VSTS) kann eine Web-Anwendung einfach gebaut und auf einen Server – in diesem Beispiel auf Azure – deployed werden. Auch der Team Foundation Server (TFS) wird dieselbe Funktionalität unterstützen, jedoch ist zum Zeitpunkt der Entstehung dieses Beitrags (Januar 2016) das neue Release Management im TFS noch nicht verfügbar.

Ziel ist es, Änderungen am Code direkt auf eine Testumgebung zu deployen und dann nach einer manuellen Freigabe diesen Stand direkt weiter auf die Produktivumgebung zu bringen. Damit bei der häufigen Durchführung dieses Prozesses das Risiko gering zu halten, wollen wir den gesamten Prozess bis auf den Freigabeschritt automatisieren so dass wir Dinge wie z.B. Tippfehler oder Vergessen der Anpassung des ConnectionStrings ausschließen können. Die Automatisierung bietet außerdem auch den Vorteil, dass wir den Deploymentprozess mittesten können. Schließlich ist er durch unsere Automatisierung wiederholbar und wenn er auf die Testinstanz funktioniert hat, sollte er mit den gleichen Schritten auch auf der Produktivinstanz erfolgreich sein.

In diesem Beispiel haben wir die Web-Anwendung in einem Git-Repository auf VSTS abgelegt.

clip_image002

Zunächst benötigen wir einen Build um die Web-Anwendung zu bauen. Wir können hierzu entweder einfach im Code-Hub den Build für den entsprechenden Branch einrichten oder im Build-Bereich einen neuen Build anlegen. In beiden Fällen können wir mit dem Visual Studio Template starten.

clip_image004

Den Build konfigurieren wir als Continous integration build der bei jedem check-in in den entsprechenden Branch ausgeführt wird. Als Default agent queue wird in dem hier gezeigten Beispiel der „Hosted“ verwendet, d.h. unser Build läuft auf einem Agent von VSTS den Microsoft bereitstellt. Für einen TFS oder alternativ auch für VSTS kann auch ein eigener Build Agent eingerichtet werden.

clip_image006

Damit wird ein Build angelegt der unsere Solution baut, Unit-Tests ausführt, die Symbols auf einem Symbol-Server publiziert und dann die Buildergebnisse in einer Drop-Location ablegt.

clip_image008

Hier müssen wir zunächst folgende Anpassungen vornehmen:

1. In den MSBuild Arguments übergeben wir folgende Parameter:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
Damit wird beim Build auch ein WebDeploy-Package erstellt

2. Als Artefakte die wir weiterverwenden wollen, genügt uns an dieser Stelle das WebDeploy Package. Deshalb laden wir nur das entsprechende ZIP-File in die Drop-Location

clip_image010

Wenn wir diesen Build nun ausführen (Queue build) sollte dieser erfolgreich durchlaufen.

clip_image012

Im nächsten Schritt wollen wir nun das im Build erstellte WebDeploy Packet auf ein Azure Web Deployen. Da unsere Anwendung auch eine Datenbank verwendet, müssen wir auf Azure eine SQL Datenbank anlegen und den entsprechenden Connectionstring in der web.config anpassen.

Glücklicherweise kann Visual Studio Release Management uns genau bei diesen Aufgaben unterstützen.

Im Release Hub legen wir nun zunächst ein neues Release an. Dafür verwenden wir das Template Azure Website Deployment.

clip_image014

Damit bekommen wir nun ein Release bestehend aus zwei Schritten, einen der das eigentliche Deployment durchführt und einen, der anschließend entsprechende Tests gegen die Website ausführt.

clip_image016

Neben dem Namen für unsere Release Definition müssen wir für den ersten Task noch eine Reihe von Parametern angeben. Zunächst wollen wir uns um die Azure Subscription kümmern. Leider kann die hier nicht einfach angegeben werden, sondern wir müssen diese in VSTS zunächst registrieren. Über Manage kommen wir zur entsprechenden Seite.

clip_image018

Hier fügen wir nun einen Azure Endpoint hinzu. Am einfachsten funktioniert die Verbindung über ein Zertifikat. Dazu wählen wir die entsprechende Option und geben dann die Subscription Id an.

clip_image020

Diese bekommt man am einfachsten aus dem Azure Portal

clip_image022

Nun brauchen wir noch das Zertifikat. Das können wir uns einfach herunterladen, indem wir in dem Feld auf den Info-Button klicken und im Tooltip dann auf „publish settings file“.

clip_image024

Daraufhin wird eine Datei heruntergeladen.

clip_image026

Wenn wir die Datei öffnen, dann finden wir darin ein ManagementCertificate das wir kopieren und in das entsprechende Textfeld einfügen.

SNAGHTML37b1ee4­

Nach Eingabe des Connection Names können wir die Registrierung des Endpoints fertigstellen.

clip_image030

Diesen Endpoint wählen wir nun in unserem Deployment Task aus.

clip_image032

Wir geben noch den Namen unserer Web App an. Dieser wird dann als Teil der URL <Web App Name>.azurewebsites.net verwendet. Daraus ergibt sich auch, dass der Name der WebApp eindeutig sein muss und zwar über alle Azure Web Apps und nicht nur meinen eigenen Account. Da wir hier zunächst einmal das Deployment auf eine Testinstanz implementieren wollen, geben wir den entsprechenden Namen an. Und wir definieren noch in welchem Azure Datacenter unsere Web App laufen soll über das Feld Web App Location.

Nun brauchen wir noch eine Datenbank. Währen der Release Management Deployment Task die Web App anlegt, sollte diese nicht vorhanden sein, gilt das nicht für die Datenbank. Das liegt daran, dass das gesamte Deployment eigentlich nur unsere Website auf Azure kopiert und dann konfiguriert. Die Datenbank wird dann erst beim Start der Anwendung durch das Entity Framework angelegt. Entity Framework wird dann auch später für die entsprechenden Schema-Updates sorgen. Darum müssen wir uns also nicht kümmern. Wir legen einfach mit Hilfe des Azure Portals eine Testdatenbank für unsere Testinstanz an.

clip_image034

Zurück im Releasemanagement Hub können wir die Variablen für unsere Environment konfigurieren.

clip_image036

Hier geben wir nun die Parameter für den Connection String zu unserer Datenbank ein. Die Parameter haben dabei folgende Bedeutung:

AdministratorLogin: Benutzer der Administrator-Berechtigungen auf unserer Azure SQL Instanz hat (Wurde beim Anlegen des SQL Servers im Portal definiert)

AdministratorLoginPassword: Das Passwort zum obigen User

ConnectionStringName: Der Name des ConnectionStrings in unserer web.config

DatabaseName: Der Name der Datenbank die wir im vorherigen Schritt angelegt haben

ServerName: Der Name des Azure SQL Servers. Dieser wird ohne Domäne angegeben, also nur vokabelchef statt vokabelchef.database.windows.net

clip_image038

Aus diesen Variablen wird dann das Feld Additional Arguments befüllt die in unserem Fall die Parameter an WebDeploy weiterreicht.

Nun müssen wir unsere Release Definition noch mit einem Build verknüpfen.

clip_image040

clip_image042

Wir speichern die Release Definition und können nun ein Release über den Release Button starten. Nachdem wir einen Build ausgewählt haben und die Environment selektieren bis zu der unser Release laufen soll – aktuell haben wir ja nur eine Environment – kann es losgehen.

clip_image044

Wir sollten nun ein erfolgreiches Release erhalten. Im Protokoll sieht man, wie die entsprechende Web App angelegt und die Anwendung installiert wurde.

clip_image046

Bei meinen Tests sind hin und wieder Probleme aufgetreten, wenn die Web App neu erstellt werden musste. Das scheinen Timing-Probleme zu sein, so dass das Anlegen der Web App noch nicht komplett abgeschlossen ist und schon versucht wird dort hinein die Anwendung zu kopieren. Eine Wiederholung des Releases hat dabei immer geholfen, was nicht so tragisch ist, da das Anlegen der Web App ja meist nur einmal durchgeführt wird.

clip_image048

Wenn das Release erfolgreich war, können wir unsere Webseite über <Web App Name>.azurewebsites.net aufrufen.

clip_image050

Im Azure-Portal kann nun ggf. noch der Tarif für die Web App angepasst werden.

clip_image052

Um zu prüfen, ob die Daten auch korrekt in unserer Datenbank ankommen und um diese auch direkt bearbeiten zu können, kann man nun noch den Zugriff auf die Azure SQL DB von extern ermöglichen. Dazu im Azure Portal unter SQL databases die entsprechende Datenbank auswählen, dann auf den Link unter Server name klicken und dort dann unter All settings die Option Firewall auswählen. Mit Add Client IP kann nun die IP Adresse des aktuellen Clients freigeschaltet werden.

clip_image054

IM Visual Studio kann im Server Explorer nun eine Datenverbindung hinzugefügt werden

clip_image056

Wie man sieht, wurden die Daten korrekt abgespeichert.

clip_image058

Als nächstes wollen wir unsere Infrastruktur auf 2 Environments (Stages) erweitern, so dass wir die erste Environment für Tests, die zweite als Produktivinstanz verwenden können. Dazu klonen wir die bestehende Instanz einfach.

clip_image060

In der geklonten Instanz passen wir dann die Variablen und den Namen der Web App entsprechend an.

Wichtig: In der geklonten Environment muss das Passwort nochmals neu eingegeben werden, da dieses nicht mit kopiert wird!

clip_image062

Die Datenbankinstanz müssen wir wie im ersten Schritt noch anlegen.

clip_image064

Nachdem wir abschließend die beiden Environments sinnig benannt haben, können wir ein erneutes Release starten. Hier können wir nun einstellen, dass das Release bis zur Produktivinstanz verteilt werden soll.

clip_image066

Nun wollen wir noch den manuellen Freigabeschritt einbauen, da momentan ja, der Release Prozess bis zur Produktion durchläuft, sofern unsere Tests erfolgreich sind. Dazu können wir die Funktion „Assign approvers“ nutzen.

clip_image068

Hier konfigurieren wir, dass das Pre-deployment approval nicht automatisiert erfolgen soll, sondern wir tragen einen oder mehrere Benutzer ein, die die entsprechende Berechtigung erhalten. Zudem aktivieren wir eine Email notification.

clip_image070

Abschließend stellen wir unsere Release Definition noch auf Continous Deployment um.

clip_image002[7]

Wenn wir nun Codeänderungen in der Versionsverwaltung einchecken, dann wird zunächst ein Build getriggert der dann unseren Releaseprozess anstößt welcher bis auf die Testinstanz automatisiert ausgeführt wird. Dann wird eine Benachrichtigungsmail an den Approver versendet und nachdem der das Release freigegeben hat, wird das Release weiter auf die Produktivinstanz transportiert. So macht Continous Delivery Spass!

Aktuelles

Nach oben