Team Build – Erster Eindruck

Jürgen Gutsch — Wed, 23 Mar 2011 09:34:37 GMT

Mein erster Eindruck vom Team Build des TFS 2010 ist leider sehr negativ.

Die Gründe sind zum einen die Umsetzung mit der Workflow Foundation 4.0 und die dadurch entstandene Komplexität, bzw. die verringerte Flexibilität. Selbstverständlich kann man Team Build auch weiterhin mit MSBuild nutzen, ist aber aus meiner Sicht genauso eingeschränkt wie in der Version 2008. Die Workflow Foundation hat Team Build nicht einfacher gemacht, sondern noch komplexer.

Natürlich lässt sich der Workflow mit eigenen Activities ergänzen und erweitern, allerdings müssen die erst Programmiert und getestet werden. Einen vorhandenen Build auf den neuen Team Build 2010 zu migrieren, ist aufgrund des zu hohen Aufwands eher unsinnig. Der Aufwand erhöht sich, wenn Microsoft-fremde Komponenten wie z. B: NUnit genutzt und ausgewertet werden sollen.

Fängt man mit einem komplett neuen Build-Prozess, einem neuen Projekt an und hat man bereits ausreichend Erfahrungen mit der Workflow Foundation 4.0 macht Team Build eventuell mehr Sinn und kann in diesem Fall auch relativ flexibel werden. Komplex bleibt es dennoch.

Die eigene Migration

Die Migration die ich jetzt vorgenommen habe, sieht lediglich so aus, dass ich die Sourcen statt von der alten Versionsverwaltung, nun vom TFS hole:

1. Continous Integration

Hudson der für die Continous Integration und die Nightly Builds zuständig ist, wurde lediglich um das TFS-Add-In erweitert. Die Sourcen werden nun vom TFS geholt, statt vom SVN. Das ist alles. Gebaut und getestet wird dann wie zuvor auch.

2. Release Build

Die Migration, des rein auf MSBuild basierende Release Builds war etwas kniffliger, da es keine vernünftigen MSBuild-Tasks gibt. Hier war der Weg über die tf.exe nötig sowie die Auswertung der Konsolenausgabe.

Folgende Anforderungen muss das Release Build erfüllen:

Unterscheidung zwischen Test-Build (für die Software-Tester) und Release Build.
Ermitteln der aktuellen Revisionsnummer, wenn keine übergeben wir.
=> Zugriff auf die Versionsverwaltung
Holen der aktuellen Sourcen
=> Zugriff auf die Versionsverwaltung
Updated die Versions-, Build-, und Revisionsnummer in den AssemblyInfos
Bauen der Anwendungen (4x Server; 8x Client)
Kopieren der Artefakte in die Zielverzeichnisse
Ermitteln der Revisionsinformationen seit dem letzten Build
=> Zugriff auf die Versionsverwaltung
Kopieren der Revisionsinformationen in die Zielverzeichnisse
Label im TFS setzen
=> Zugriff auf die Versionsverwaltung
Versandt der Erfolgs-E-Mail an alle beteiligten

Alle Zugriffe auf die Versionsverwaltung gehen nun über die tf.exe. Die Auswertung der Konsolenausgabe erfolgt per MSBuild-Taks (entweder mit den vorhandenen Tasks von Microsoft, den MSBuild Community Tasks oder dem MSBuild Extension Pack)

Den vorhandenen Build einfach umzubiegen war somit trotz einiger kleinen Hürden wesentlich einfacher als auf Team Build 2010 zu migrieren

Fazit

Team Build nutzen: Ja, wenn man Workflow Foundation 4.0 kennt und ein neues Projekt anfängt und Microsoft Technologie zum Testen der Software nutzt.

Team Build nutzen: Nein, wenn man migriert, Workflow Foundation 4.0 nicht kennt, Test-Frameworks nutzt die nicht von Microsoft stammen und/oder den Build einfacher anders machen kann.

Sehr gerne hätte ich Team Build genutzt, um auch hier den vollen Umfang vom TFS zu nutzen. Sehr gerne hätte ich die Testberichte aus den NUnit-Tests im TFS integriert gesehen. Aber der enorme Aufwand wäre einfach nicht vertretbar gewesen.

Developement Infrastructure

Jürgen Gutsch — Fri, 18 Mar 2011 20:46:00 GMT

Meine heutigen Fragen und Anmerkungen auf Twitter, welche Team Build mit der Workflow Foundation betrafen und die problematische Migration von SVN zum TFS (die ich ebenfalls auf Twitter kommentiert habe) mag wohl den Eindruck gehabt haben, dass die von mir genutzte Developement Infrastructure nur auf Microsoft-Technologie basiert.

Weit gefehlt :-)

Developement Infrastructure

Aber fangen wir mal von ganz vorne an. Wie sieht eine Developement Infrastructure aus?

Das wichtigste Werkzeug ist natürlich das Visual Studio 2010 mit allen seinen Plug-Ins (die bei mir mehrheitlich von JetBrains stammen)
Als nächste kommt die Versionsverwaltung, wie z.. B: Git, Mercurial, SVN oder eben den TFS.
Ebenfalls wichtig halte ich die Integration der Versionsverwaltung in das Visual Studio. Hier kommen z. B: die Tortoise-Varianten und eben der Team Explorer zum Einsatz
Ebenfalls wichtig ist ein Build-Server der mit der Versionsverwaltung zurecht kommt, Änderungen mitbekommt und daraufhin einen sog. Continous Integration Build erzeugt und die automatisierten Tests ausführt. Optimaler weise ist der auch für den Nightly-Build zuständig, der die täglich, frische Version für die Tester oder den Kunden auswirft
Als Buildserver wird Team City, Hudson, Cruis Control oder eben Team Build eingesetzt.

Idealerweise gibt es einen Server der für die Versionsverwaltung zuständig ist und einen der nur die Builds macht. Das gilt auch für den TFS: der TFS und Team Build sollten auf zwei verschiedenen Servern installiert werden.

Meihne Einstellungen zum TFS

Der TFS ist klasse. Ich habe seit der ersten Version des TFS mit diesem gearbeitet, aber ich nie Team Build als Build-Server verwendet. Der TFS ist eine ideale Versionsverwaltung für Firmen, die ein bisschen mehr Kontrolle wollen, als es andere Systeme bieten. Mit dem Integrierten Bug-Tracking funktioniert auch das Projektmanagement hervorragend. Agile Softwareentwicklung ist mit dem TFS hervorragend machbar, solange man die vorgegebenen Prozesse etwas anpasst oder sich an die Prozesse des TFS anpasst. Sobald der TFS allerdings mal eingerichtet ist, ist es aus meiner Sicht im Moment das beste System auf dem Markt. Mit Team Build und Lab Management bietet es einige weitere (im Prinzip) hervorragende Features, die ich bisher leider nie selber verwendet habe.

Wie Albert Weinert allerdings ganz richtig per Twitter eingewendet hat: “wenn du in der MS Welt bleibst mag es TFS ja nett sein”

Privat würde ich den TFS allerdings nie verwenden. Das liegt nicht nur an den Lizenzkosten, sondern auch am Overhead den der TFS mit sich bringt, der für einen alleine oder auch zu zweit einfach zu groß ist. Das geht nämlich auch einfacher und ohne dass man mehrere Tage damit verbringen muss, dass System anzupassen.

Private Infrastructure

Privat nutze ich aktuell vorzugsweise Mercurial als Versionsverwaltung. Für meine privaten Projekte auf meinem eigenen Server und Kiln, für öffentliche Projekte auf BitBucket.

Das Svn2Tfs Migration Tool wird ebenfalls auf BitBucket als Open Source zur Verfügung gestellt

Ich nutze auch Git unter GitHub um vorhandene Projekte zu Forken, zu beobachten oder mich daran zu beteiligen.

Als Buildserver kommt Hudson, das ich als schnellstes, einfachstes und bequemsten zu installierenden Buildserver kennengelernt habe. TeamCity hat mir von Anfang an zu viele Ressourcen benötigt, ist zwar zwar intuitiv und schnell eingerichtet, benötigt aber sehr viel Arbeitsspeicher, was allerdings auf einem privat gehosteten Server rar sein kenn. CruiseControl ist bei mir wegen der umständlichen Konfiguration gleich ausgeschieden.

Hudson dagegen kann erst mal fast nichts (aus .NET-Entwicklersicht, ist es fast nichts, wenn es nur Javaprojekte bauen kann), ist aber durch unzählige Plug-Ins erweiterbar, die direkt in der GUI aktiviert und konfiguriert werden können. Hudson belauscht alle meine Repositories und führt bei Änderungen sofort einen Continous Integration Build aus, führt alle Tests (mit NUnit) automatisiert aus und erstattet mir im Fehlerfall ausführlich Bericht.

Geschäftliche Infrastructure

Als ich im Geschäft angefangen habe gab es einen exotisch installierten SVN-Server… und immerhin gab es einen SVN-Server :-)

Hudson war schnell installiert und Continous Integration war somit eingerichtet. Release Builds wurden noch mit FinalBuilder gemacht, was bis dahin auch einigermaßen gut funktionierte…

Bis Jürgen kam… Und den Buildprozess (auch auf den Entwicklungsrechnern) beschleunigte, indem er alle Projektreferenzen durch Assembly-Referenzen ersetzte. Dadurch wurde nicht nur der Lokale Build beschleunigt, sondern theoretisch auch der Build unter FinalBuilder. Problem nur: Durch die fehlenden Projektreferenzen mussten die Projektabhängigkeiten von Hand gesetzt werden. Was Hudson und MSBuild mitmacht, wurde von FinalBuilder ignoriert, ganz egal ob der FinalBuilder per Visual Studio baut, oder per MSBuild. FinalBuilder war also für mich, unter anderem auch deswegen, für mich gestorben.

Hätte ich (wie es Stefan Lieser per Twitter anmerkt) die Build-Reihenfolge mit mehreren einzelnen Solutions vorgenommen, statt mit einer großen Solution, hätte ich den Build-Prozess im Final Builder unter Umständen immer wieder anpassen müssen, wenn sich die Projektstruktur ändert. In der aktuellen Entwicklung konnte sich die Struktur aber laufend ändern, da auch eine ganze Menge Testprojekte durch die neu eingeführten Unit-Tests hinzukamen oder die Unit-Tests zu Refactorings zwingen konnten.

Die Lösung war, den FinalBuilder-Prozess mit MSBuild sauber und generisch nachzubilden. Ein paar MSBuild-Tricks waren auch in den Projektdateien nötig und der Prozess war getan. Sehr Dankbar bin ich übrigens dem Thorsten Hans, der mich dabei mit wertvollen Tipps unterstützt hat.

Desweiteren war der Build mit MSBuild doppelt so schnell, als der mit FinalBuilder. Der Overhead der Überladenen GUI des FinalBuilder macht sich im Vergleich zur Konsole bemerkbar. Der Aufruf: “msbuild buildall.proj” erzeugt nun aus den Sourcen, in einer halben Stunde vier Server-Produktvarianten und sechs Client-Produktvarianten, inklusive WiX-Setup-Projekten.

Wir haben nun also einen exotischen SVN-Server, CI mit Hudson und MSBuild und einen Build-Prozess mit MSBuild.

Bleibt das Problem mit dem Bug-Tracking das irgendwie in einem Sharepoint zusammengebastelt war. Eine direkte Verknüpfung zwischen Änderungen am Code und Bug-Tracking gab es nicht. Im SVN wurde nur eine Ticket-ID mitgespeichert.

Die Lösung war der TFS, indem die komplette History aus dem SVN migriert werden sollte

Hier kommt das oben erwähnte Svn2Tfs Migration Tool zum Einsatz, das nacheinander alle Revisionen komplett mit Kommentaren vom SVN lädt und in den TFS einspielt.

Existierende Migrationstools funktionierten aufgrund des exotischen SVN-Servers nicht und brachen mit Fehlern ab. Woraufhin ich selber ein Migrationstool schrieb. Innerhalb von vier Tagen waren ca. 8100 Revisionen von 200.000 Dateien migriert.

Die Migration der alten Tickets als neue WorkItems erfolgte dann relativ stupide per Excel

Stand Heute: TFS als Versionsverwaltung, TFS als Bug-Tracking, Hudson für die CI-Builds und MSBuild für den komplett-Build.

Team Build

Jetzt wo der TFS installiert und eingerichtet ist, war die Überlegung, die CI-Builds auch per Team Build zu machen, was im ersten Schritt aber schon daran scheiterte, dass die Build-Prozesse mit der Workflow Foundation 4 so komplex sind, dass es auf die Schnelle nicht möglich war dem Team Build beizubringen, dass wir nicht MSTest, sondern NUnit als Unit-Test Framework verwenden.

Schade eigentlich, den ich verspreche mir von Team Build, dem Lab Management und den Codet-UI-Tests die Testabteilung stärker in den TFS-Prozess zu integrieren.

Es fehlt also eine Integration von Manuellen Tests, automatisierten Akzeptanz-Tests und UI-Tests

Das werde ich möglicherweise nun anders lösen müssen.

Dafür war FittNesse eine Idee. Für weitere Ideen bin ich absolut offen. :-)

Fazit

Somit entwickle ich zwar auf Microsoft Plattformen, nutze aber nicht nur Microsoft Technologien.

Stichwort: ALT.NET (unter anderem das Motto der letztjährigen See# Party)

Microsoft entwickelt immer bessere Developement Infrastructure. Mit jeder Version wird der TFS besser. Mit jeder Version wird das Visual Studio und seine Tools besser. Aber im Moment ist man stellenweise immenroch besser mit alternativen Tools und Frameworks dran ;-)

Search results matching tags 'NUnit' and 'Continous Integration'

Team Build – Erster Eindruck

Developement Infrastructure