Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Continuous Delivery: ASP.Net MVC Applikationen mit Azure und Team Foundation Service

Mittwoch, 05. September 2012

Bei Continuous Delivery geht es um die Erweiterung von Continuous Integration um ein ständiges Deployment in eine Produktivumgebung. Wir zeigen, wie sich dies mit ASP.Net MVC Applikationen und Windows Azure bewerkstelligen lässt. Als Ergänzung zeigen wir, wie Team Foundation Service – TFS in der Cloud – das Deployment weiter vereinfacht.

Projekt-Setup

Im ersten Schritt wird eine neue MVC 4 Applikation in Visual Studio 2012 erstellt:

SNAGHTMLc94dc5

Diese wird direkt im Team Foundation Service eingecheckt – doch mehr dazu später.

Die Webseite soll in Windows Azure – der Cloud-Plattform von Microsoft – gehostet werden. Dazu wird über das Management-Portal von Azure unter http://manage.windowsazure.com eine neue Website erstellt:

image

An dieser Stelle wird die Website http://aitdemobuild.azurewebsites.net erstellt.

Hinweis: In jeder MSDN stecken “Freiminuten” für Windows Azure die Sie unter Angabe einer Kreditkarte aktivieren können. Die Kreditkarte ist dabei mit einem Limit von 0 € belegt. Die Höhe des Freikontingentes richtet sich nach Ihrer MSDN.

Semiautomatisches Veröffentlichen

Über das Dashboard im Management-Portal kann anschließend eine Datei mit Deployment-Einstellungen für Visual Studio heruntergeladen werden:

image

Diese Datei wird im MVC4-Projekt der Visual Studio Solution importiert. Den entsprechenden Dialog erreichen Sie über das Kontextmenü des Projektes im Solution Explorer unter dem Punkt “Publish…” bzw. “Veröffentlichen”.

SNAGHTML13ec2b8

Der Import setzt alle Einstellungen entsprechend auf Ihr Azure-Konto:

SNAGHTML13f55b4

Nach dem Klick auf Publish wird die Azure-Website entsprechend befüllt:

image

Continuous Deployment

Einen Screenshot der leeren MVC4 Webapplikation sparen wir uns an dieser Stelle und widmen uns stattdessen dem automatischen Publizieren der Webseite via TFS speziell Team Foundation Service aka http://tfspreview.com. Im ersten Schritt hatten wir die Solution mit der Webseite bereits in einem Teamprojekt in Team Foundation Service eingecheckt.

Im nächsten Schritt aktivieren wir das Publizieren in Azure aus dem Teamprojekt. Dazu

image

Man sieht, dass Team Foundation Service nur eine Option ist – GitHub die andere…

Nach der Auswahl müssen URL und Credentials für den Team Foundation Service Account angegeben werden und schließlich kann man das Teamprojekt auswählen:

image

Eine mystische Meldung vermittelt die “Verlinkung” der Azure Website mit dem Teamprojekt:

image

Dahinter verbirgt sich die Einrichtung eines Continuous Integration Builds der nach dem Erstellen der Webseite das Deployment in die Cloud übernimmt. Dazu wird eine Build-Definition angelegt:

image

Das kleine Kreuz der Build-Definition “aitdemobuild_CD” zeigt, dass die Definition erst einmal deaktiviert ist. Der nächste Schritt ist also das Bearbeiten der Definition: Nach dem Aktivieren ím ersten und Workspace-Einrichten im dritten Tab, gelangen wir zum “Process”-Tab:

image

In diesem müssen die Solution sowie das Web Deploy Script (siehe obiges Publish-Script) angegeben werden. Beachten Sie, dass die Pfade im Workspace entsprechend gemappt sind!

Wenn man sich das “Process”-Tab genauer anschaut, erkennt man, dass nicht das DefaultTemplate.11.xaml als Build Process Template eingesetzt wird, sondern ein spezielles AzureContinuousDeployment.11.xaml. Dieses wurde ebenfalls im obigen Verlinkungs-Schritt angelegt – sprich im Ordner BuildProcessTemplates der Source Control eingecheckt.

Wird nun also eine Änderung an der Website eingecheckt oder der Build manuell ausgelöst, kann man das nicht nur im Visual Studio, sondern auch im Azure Management Portal verfolgen:

image

Nach etwas Zeit erscheint der fertige Deployment-Eintrag:

image

Auf Seiten TFS lief also ein ganz normaler Build, der am Ende jedoch die Ergebnisse in die Cloud einstellte. Zudem werden bei Builds via Team Foundation Service alle Build-Ergebnisse im Source Control unter dem Ordner $/TeamProject/Drops eingecheckt. Das liegt daran, dass der Build ja auf einer temporär erstellten virtuellen Build-Maschine in Azure abläuft, die nicht unbedingt Zugriff auf unsere lokalen Netzwerk-Shares haben soll:

image

Abseits von Hello World

Azure bietet über ein einfachen Deployment natürlich mehr für Webseiten. So können beispielsweise Datenbanken als neue Ressourcen hinzugefügt werden:

image

Fazit

Microsoft vereinfacht das Deployment in die hauseigene Cloud mit Team Foundation Service deutlich. Wie das für lokale Team Foundation Server aussieht, wird derzeit noch nicht bekanntgegeben – man darf gespannt sein!

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , ,

Hinterlasse eine Antwort