HowToCode: Build/Deployment/WTF oder auch Automatisierung mit MSBuild
In meinen Azubitagen habe ich mich doch des häufigen gefragt was denn nun ein Build oder ein Deployment ist. Mit der Zeit habe ich mich nun doch mit dem Mysterium beschäftigt und sogar angefangen mit MSBuild verschiedene Prozesse zu automatisieren. Wie sieht euer Prozess aus?
Grundbegrifflichkeiten
Ich will jetzt keine Wikierklärung von Build oder Deployment bringen sondern es mal auf das wesentliche runterbrechen bzw. soweit erklären wie ich es auch meinen Azubis weitergebe (wenn ich Quatsch erzähle, dann ist jetzt eure Chance mich zu korrigieren 
)
- Das “bauen” (“Build”) von Software passiert z.B. immer wenn ihr im Visual Studio auf den “Run” Button drückt. Im Hintergrund wird der Code kompiliert und im Falle einer ASP.NET Webanwendung wird der Development Server gestartet oder der lokale IIS.
- Beim “Deployment” versteht man das letztendliche veröffentlichen der (gebauten) Software auf einen Webserver bzw. wenn man Clientsoftware hat spricht man auch vom “Rollout”.
Wenn euer Deployment-Prozess daraus besteht das ihr im Visual Studio auf “Build” drückt und das Ergebnis dann veröffentlicht, dann sollte man sich jedenfalls im professionellen Bereich Gedanken machen
Diese Prozesse kann man teilweise auch automatisieren. Jedenfalls bis zu einem gewissen Grad.
MSBuild
“MSBuild” ist das Build Framework von Microsoft. Visual Studio nutzt beim Klick auf den “Run” Knopf auch MSBuild. Natürlich kann man MSBuild auch per Kommandozeile aufrufen. Dadurch ist es möglich z.B. das bauen der .NET Anwendungen zu automatisieren. Auf die Möglichkeiten und was wir bisher machen gehe ich später noch kurz ein.
Ein genialer Einstieg zum Thema findet sich auf dem Blog von Thorsten Hans:
Das MSBuild Universum
“Continuous Integration”
In einem anderen Post bin ich bereits auf “Continuous Integration” eingegangen. Dort habe ich bereits angeschnitten was man noch für Möglichkeiten hat – jetzt möchte ich mal konkreter benenne wie wir das gelöst haben:
In unserem Projektteam haben nutzen wir die TFS2008 Teambuilds:
- Über den Teamexplorer werfe ich ein neues Deployment an.
- Dieses holt die Sourcen und baut die Solution.
- Die gebaute Website wird nun in unsere gewünschte Ordnerstruktur (wie sie auf dem Dev/Test/Livesystem ist vorhanden ist) gebracht
- Die “richtige” .config wird ausgewählt und in das config Verzeichnis geschoben.
In unserer Entwicklungsumgebung wird nun dieser Ordner auf den Webserver der Entwicklungsumgebung kopiert und fertig.
Auf den anderen Umgebungen zippen wir diesen Ordner und können diesen dann entsprechend kopieren und dann mit wenigen Handgriffen (kann man das evtl. aber noch mit Powershell oder VBScripts verbessern? -> siehe weiter unten) “live” schalten.
Wir sind auch schon (fast) zufrieden damit. Besonders auf unserer Entwicklungsumgebung hat dies sehr viel Zeit gespart, dass wir per Klick (über MSBuild und ein simplen xcopy Befehl) ein Deployment durchführen können.
Unterstützende MSBuild Packs:
Da MSBuild von Haus aus nicht sooo viel mitbringt, haben sich die beiden “Tools” sich noch bewährt:
Was vielleicht noch cool wäre…
Mit dem TFS2010 wird ja alles besser ( ), aber was ich mir noch nett vorstelle wären diese Sachen:
- MSDeploy. Alexander Groß hatte dies auch beim .NET UG Treffen vorgestellt und es wäre sicherlich einen Blick wert. Besonders um IIS Settings “zu ändern” wäre es evtl. hilfreich. Unser Buildserver hat keine direkte Verbindung zu Test bzw. Live (was ja auch ok soweit ist), doch wie kann man z.B. den Home Directory Pfad der Webanwendung auf den neuen Pfad lenken (die alten Versionen bleiben noch auf den Maschinen liegen)? Mit Powershell? Oder einem VBScript? Vorhanden ist ein IIS6
- UI-Tests. Gibt es da vielleicht eine einfache Möglichkeit? Selenium oder gibt es etwas leichtgewichtigeres? Macht das denn überhaupt Sinn solche Tests auszuführen?
- Die Changesets (und verbundene Tasks/Bugs) vom TFS seit dem letzten Deployment und die damit verbundenen Tasks – hat da jemand Erfahrung oder einen Blogpost zur Hand?
Wie macht ihr das? Welche Tools und Vorgehensweisen haben sich bei euch bewährt?
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
André Krämer
19. March 2010
Im Zusammenspiel mit dem TFS kann ich den TFS Deployer (http://tfsdeployer.codeplex.com/) sehr empfehlen. Damit kannst du in Abhängigkeit von der Buildqualität in verschiedene Umgebungen deployen (bzw. Powershell Scripte rennen lassen, die dann deployen).
Ich nutze dass in einem Projekt um so über den Teamexplorer in Test / QS oder Integration zu deployen. Eine sehr feine Sache!
Daniel
19. July 2010
Hi, zum Thema UI Test: Hast du schon mal “Watin” probiert? Macht einen guten Eindruck.
http://watin.sourceforge.net/
Robert Mühsig
19. July 2010
Ich hab es in dem Mvc Codecamp Server Projekt auf Codeplex gesehen. Sieht interessant aus. Da wir in der Firma den TFS 2010 zur Verfügung haben, würde ich aber erst einmal dort die TFS UI Tests näher betrachten. Wenn kein TFS vorhanden wäre, ist das bestimmt sehr cool. Aber wahrscheinlich auch mit viel Tipparbeit verbunden.