Team Foundation Server / TFS – Segen oder Fluch?

TFS Bashing gehört bei Twitter ja zum guten Ton (und ich mach ab und zu mit ), aber ist der TFS wirklich nur schlecht und ein NoGo? Ich werfe mal meine Gedanken dazu ab…

 

”TFS ist klasse”

So titelt Jürgen Gutsch Blogpost und vertritt damit quasi die “Pro-TFS” bzw. “Nicht-alles-ist-schlecht-an-TFS” Seite. Das Bildchen oben kommt aus den Microsoft Werbefolien zum TFS. Neben Versionskontrolle gibt es Reportingmöglichkeiten, eine Build- und Testumgebung, Kollaboration sowie Work- bzw. Bugtracking.

Microsoft versucht mit dem TFS den kompletten Application Lifecycle abzudecken – das gelingt zum Teil, zum Teil natürlich auch nicht. Von Version zu Version wird es aber besser
Was man alles zum Lifecycle dazuzählt ist auch je nach Blickwinkel zu betrachten – so ganz scharf ist das Bild nicht.

Natürlich hat der TFS seine Macken…

Jürgen hat bereits eine nette Auflistung an Kritikpunkten zusammengestellt:

1. Die Versionskontrolle sei “ätzend” langsam (GetLatest?),
2. der TFS pfuscht in den Projektdateien rum,
3. Der TFS ist Solution-zentriert, für Micro-Workflows mit Feature-Branching ungeeignet.
4. Vom Offline-Support will ich gar nicht erst anfangen.
5. Es fehlt die Einfachheit von .gitignore
6. Builds: TFSBuild.proj war nicht schön, aber Builds mit Workflows sind der Hammer -> Mit Kanonen auf Spatzen schiessen
7. Darüber hinaus stört es wie geschlossen das System ist.
8. Ist einfach ein alles oder nichts Ansatz.

Wie Jürgen denke ich, dass einige Sachen im firmenkontext nicht so eine große Rolle spielen. Ich selbst bin tätig in der “Microsoft-Abteilung” bei der T-Systems-MMS zusammen mit ca. 100 “Microsofties” (Entwickler / Projektleiter / Tester). Wir nutzen den TFS mit (fast) all seinen Facetten. Der Rest der Firma verwendet ganz unterschiedliche Tools und Frameworks (von SVN, über Git etc. – als Firma haben wir da vieles im Einsatz).

Ich werde wie Jürgen einfach mal Punkt für Punkt darauf eingehen:

1. Die Geschwindigkeit der Versionskontrolle hat mich noch nicht wirklich gestört. Jedenfalls nicht bewusst.
2. Wenn eine Firma oder Abteilung den TFS einsetzt, dann ist das kein Kritikpunkt sondern eine Tatsache
3. Ich würde frech behaupten, dass viele Entwickler so arbeiten (eine große SLN und gut ist). Wir im Team experimentieren aber auch demnächst rum. Kann mir jetzt aber nicht vorstellen, dass das mit dem TFS total kompliziert ist.
4. Ich habe im firmenkontext noch kein Killerargument für Offline-Szenarien gefunden. Netz ist da und der TFS läuft einfach (und wird überwacht). Wenn es darum geht, dass man einchecken will ohne das Team zu behindern gibt es Shelvesets. Das ist zwar auch vom Workflow etwas umständlich, aber geht. Gefühlt habe ich dieses Feature aber noch nicht vermisst.
5. Geht auch mit dem TFS – evtl. nicht so flexibel, aber bislang hab ich das Feature nicht aktiv vermisst (aber ich kenne Git auch nicht wirklich).
6. Auf das TeamBuild gehe ich weiter unten ein.
7. Je nachdem wie man Offen/Geschlossen auslegt. Wenn man das Work-Item System gänzlich austauschen will oder den Testrunner auswechseln will, dann geht das nicht. Es gibt natürlich APIs um an Informationen zu gelangen oder um Prozesse zu verändern.
8. Die Microsoft-Tools verstehen sich am besten mit anderen Microsoft-Tools.

Wenn man nur eine Team von Entwicklern ist, dann ist der TFS sicherlich die falsche Wahl. Insbesondere da man Git oder SVN etc. Hosting relativ günstig im Internet bekommt – TFS Hosting ist jenseits von gut und böse.

Der TFS soll aber alle beteiligten im Projekt verbinden.

Ein TFS Geschädigter…

Björn Rochel hat einen sehr guten Kommentar unter Jürgens Post gesetzt. Ein kurzer Einstieg in seine Leidensgeschichte:

6 Jahre TFS haben so ihre Spuren bei mir hinterlassen. Interessanterweise war ich in diesen 6 Jahren auch mal ne Zeit lang Feuer und Flamme für den TFS. Ist irgendwie komisch, wenn ich das jetzt schreibe. War aber wirklich so. Und ja, 4 von diesen 6 Jahren hab ich auch Produktentwicklung mit dem TFS gemacht,  mit dedizierten Testern und Produktmanagern. In 6 Jahren habe ich mit Teams zwischen 5 – 50 Entwicklern am TFS zusammen gearbeitet. Aus der von Dir genannten Pyramide waren alle Ebenen vertreten dabei. Dafür sorgt schon die Normalverteilung

Björn ist ein großer Verfechter von Feature-Branching und von “Micro-Commit-Workflows”. Ich vermute hinter “Micro-Commits” sehr kleine Code Änderungen – natürlich geht beides auch mit dem TFS (jedenfalls meiner Meinung). Man hat natürlich kein “lokales Repository”, sondern entweder macht man einen Checkin oder ein Shelveset – der TFS ist der Master. Wenn die Verbindung zum TFS schlecht ist, dann dauert das natürlich. Sowas kann natürlich auch bremsen.

Mergen & Branchen – der Hass im TFS & SVN?

Björn ist der Meinung, dass mergen und branchen im TFS absolut furchtbar ist – meiner Meinung nach ist SVN zwar 20 mal schlimmer und dümmer was das mergen angeht, aber das Mergen ist wirklich ein Schmerzpunkt. Hängt aber meiner Meinung auch zum großen Teil von der Arbeitsorganisation ab. Wenn mehrere Leute zusammen an einer Datei arbeiten, dann knallt es. Muss ja. Ich kann leider nicht sagen, ob sowas bei Git um ein vielfaches einfacher ist.

TeamBuild – die TFS Build Umgebung

Ab und an habe ich über das Thema TeamBuild (und dem verbundenen MSBuild) geschrieben. Das tolle am TeamBuild? Es ist fest integriert – sowohl im TeamExplorer (Plugin für Visual Studio für den TFS), als auch in der Weboberfläche etc. – auch das Bugtracking kann Daten über Builds abrufen (“Bug gefunden in Build…”). In Verbindung mit dem Labmanagement für automatisierte Tests (Integrationstests / Web/UI-Tests) ist das sicherlich cool (leider momentan bei uns noch nicht vorhanden ).

Meiner Meinung nach ist der TFS TeamBuild Workflow fürchterlich zu bearbeiten – auch wenn es vermutlich total flexibel ist Einmal ein passendes Template gefunden (z.B. die AIT Build Suite ist kostenlos und bietet viele Einstiegsmöglichkeiten) oder gebaut erweisst es sich aber als recht praktisch.

Bei meinem Hobbyprojekt nutze ich TeamCity und bin auch ein totaler Fan davon. Insbesondere die Weboberfläche macht Spaß und es gibt für 3rd Party Tools auch gute Integrationsmöglichkeiten. Wesentlich besser ist auch das Management von Artefakten, wo das TeamBuild nur einen stupiden Fileshare hat, bietet TeamCity direkt eine “Verwaltung” von Build-Artefakten. Andere Builds können mit den Artefakten auch weiterarbeiten – sowas im TFS ist eher schlecht gelöst.

Warum nimmst du dann immer noch das TeamBuild?

TeamCity ist stark, allerdings ist bei mir noch kein Killerargument für die Firma untergekommen. TeamBuild funktioniert (einmal eingerichtet) und ist durch ein professionelles Application Management gesichert. Einfach so ein Rechner zu nehmen und TeamCity zu installieren geht in einer kleinen Firma, aber ich bin froh darüber, dass ich mich nicht um Infrastruktur sorgen machen muss.

Tooling Frage

Ich würde frech behaupten, dass ein Großteil der Entwickler mit SVN oder VSS aufgewachsen ist und Git maximal von Github kennen um sich Code zu kopieren

Der TFS hat ein nettes Tooling drumherum – SVN ist schon gruselig. Alles andere ist abenteuerlich (oder täusch ich mich?) – als kleines Team kann man das gerne machen. Wenn man hingegen erst 50 Entwickler schulen muss und wenn ich externe Leute bekomme die auch jedesmal anleiten muss bevor sie was einchecken, dann war es das auch mit der agilität

Tooling ist aber auch für mich eine großes Kriterium und irgendwie wirken andere VS Plugins (oder Kommandozeilenaufrufe) alles andere als sexy.

Nach links und rechts schauen

Meine völlige Unkenntnis über Git etc. kann mich natürlich verblenden, daher schaue ich natürlich auch was es noch gibt – wie z.B. mit TeamCity. Aber das Tooling hemmt mich noch

Weder Segen, noch Fluch: TFS ist ein Allrounder

Der TFS kann alles (jedenfalls vom Featureset was ich momentan benötige), aber nicht alles perfekt oder sehr gut – dedizierte Tools wie z.B. ein TeamCity für das Buildmanagement können natürlich den TFS überbieten. Ob sich aber die kleinen Feinheiten der anderen Tools wirklich lohnen muss jedes Team für sich entscheiden.

About the author

5 Responses

1. 

   Robert Mischke

   20. March 2011

   Nach dem Wechsel von SourceSafe zu SVN hatte ich das Gefühl, so soll Versionskontrolle funktionieren. Schnell, einfach, stabil. Gut zu Administrieren + gutes Tooling. SVN rules!

   Nach dem Wechsel von SVN zu GIT war der Effekt noch stärker. Wow das ist schnell! Wow mergen muß kein Pain sein. Mächtig, prächtig, alter Falter! (Wobei die Lernkurve im Vergleich hoch war).

   Ich habe den Eindruck, dass TFS Bashing kommt aus der erlebten Erfahrung, dass GIT (und mercurial) ein Quantensprung im Vergleich ist!

   Alles was jenseits von Versionskontrolle im TFS geboten wird, läst sich sehr gut bis besser von Teamcity + guten PM Tools abgebilden. Der Schmerz liegt also in der Versionskontrolle.

   Wirklich äußern darf sich wohl nur jemand, der viel GIT oder mercurial Erfahrung hat u. Erfahrungen mit TFS. Fraglich nur, ob sich da jemand findet, der sich für TFS ausspricht.

   Reply
2. 

   Robert Mühsig

   21. March 2011

   Ich bin ja neugierig – wie würde man den loslegen? Einfach z.B. mein momentan auf codeplex gehostete Projekt auf GitHub umziehen?

   Reply
3. 

   Robert Mischke

   21. March 2011

   Das ist sicher ein gute Idee (Wobei ab auf codeplex ja auch mercurial angeboten wird). Github gibt dem Code auch ein schönes Gewand.

   Reply
4. 

   mgri

   21. March 2011

   Bloss mal ein Hinweis weil hier immer TFS (und CVS/SVN, …) mit Git (und Bitkeeper, Mercurial, …) verglichen wird: Die haben völlig verschiedene Grundkonzepte -> Äpfel mit Birnen.

   TFS und Konsorten sind eben kein verteiltes VCS und wollen das auch garnicht sein. TFS und Konsorten sind *per Design* für zentralisierte Umgebungen mit permanenter Connectivity gedacht, und machen sich weniger Gedanken um Merging – weil sie es eben nicht so brauchen wie ein verteiltes VCS.

   Solche Vergleiche sind also eher wenig sinnvoll.

   Reply
5. 

   Robert Mischke

   21. March 2011

   @mgri Du kannst auch DVCS zentralistisch verwenden. Dann ist GIT, Mercurial immer noch um einen Quantensprung besser als SVN und Sourcesafe DVCS oder VCS hin oder her, einfaches, leistungsfähiges Mergen und Geschwindigkeit (Bei der Suche nach Änderungen, Dateien, Browsen von historischen Versionsständen) sind ein Pluspunkt.

   Reply