Mehr von Jürgen Gutsch

Mehr von Jürgen Gutsch

Empfehlungen von Jürgen Gutsch

Blog-Empfehlungen von Jürgen Gutsch

Willkommen bei ASP.NET Zone. Anmelden | Registrieren | Hilfe

Jürgen Gutsch

ASP.NET und mehr...

News

  • It's like a whiteboard with super powers: Taskplanung mal anders mit Trello
Team Build – Erster Eindruck

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.

DotNetKicks-DE Image
Posted: Mittwoch, 23. März 2011 10:34 von Jürgen Gutsch

Kommentare

Keine Kommentare

Anonyme Kommentare sind nicht zugelassen