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:
- Die Versionskontrolle sei "ätzend” langsam (GetLatest?),
- der TFS pfuscht in den Projektdateien rum,
- Der TFS ist Solution-zentriert, für Micro-Workflows mit Feature-Branching ungeeignet.
- Vom Offline-Support will ich gar nicht erst anfangen.
- Es fehlt die Einfachheit von .gitignore
- Builds: TFSBuild.proj war nicht schön, aber Builds mit Workflows sind der Hammer -> Mit Kanonen auf Spatzen schiessen
- Darüber hinaus stört es wie geschlossen das System ist.
- 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:
- Die Geschwindigkeit der Versionskontrolle hat mich noch nicht wirklich gestört. Jedenfalls nicht bewusst.
- Wenn eine Firma oder Abteilung den TFS einsetzt, dann ist das kein Kritikpunkt sondern eine Tatsache ;)
- 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.
- 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.
- 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).
- Auf das TeamBuild gehe ich weiter unten ein.
- 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.
- 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.
