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?