TFS 2010. Schädling oder Pfau?

200px-DoNotFeedTroll_svgVor kurzem wurde von einigen renommierten Softwareentwicklern und –architekten ein Blogpost von Derek Hammer via Twitter verbreitet, in dem Derek feststellt, dass sich der Team Foundation Server zerstörerisch auf unsere Entwicklungskapazitäten auswirkt.

Neben der generalisierten Aussage “TFS Sucks” geht Derek allerdings auch im Einzelnen auf die Standbeine des Microsoft ALM Werkzeuges ein: Version Control, Bug Tracking, Project Management, Build System und Integration.

Während ich einige seiner Kritikpunkt nachvollziehen kann, sehe ich andere wiederum eher kritisch. Mein Feedback auf Twitter, es handele sich hier um gefährliches Halbwissen zog entsprechend die Nachfrage von Ralf Westphal nach sich, ob ich argumentativ den TFS “gebührend zu einem Pfau der technischen Führerschaft und Offenheit” machen könne. Obwohl es nicht meine Absicht war, den Eindruck zu erwecken, es handele sich beim Team Foundation Server um einen Pfau (ganz gleich ob führend oder offen), habe ich natürlich nichts dagegen, dennoch einige Halbwahrheiten näher zu beleuchten.

Version Control

Der größte Kritikpunkt scheint hier der zentralisierte Ansatz der Versionskontrolle zu sein. Bevor aber die eher subjektive Beantwortung der Frage danach, was möglicherweise besser sei gesucht wird (zentralisiert wie TFS oder dezentralisiert wie z.B. Git), macht es Sinn, sich zu überlegen, was denn überhaupt u.a. das Ziel einer Versionskontrolle ist.

  1. Die Arbeit am Quellcode muss runter vom lokalen System
  2. Der Quellcode muss für andere Entwickler verfügbar und lokalisierbar sein
  3. Änderungen am Quellcode müssen einfach nachvollziehbar sein
  4. Änderungen müssen einfach zusammengeführt werden können

Dezentrale, oder: Verteilte Versionskontrolle fördert die lokale Arbeit, da keine Verbindung zum Server notwendig ist. Während dieser Ansatz auf der einen Seite natürlich die Arbeit (für den Einzelnen) vereinfacht (da er immer und überall arbeiten kann ohne sich über seine stabile und hoffentlich performante Internetanbindung Gedanken machen zu müssen), frage ich mich auf der anderen Seite wiederum, welche Entwickler das sind, die sich überhaupt darüber Gedanken machen müssen?

Derek erklärt in dem Kontext, die Arbeit im Umfeld des TFS würde vollständig zum Erliegen kommen, wenn das Netzwerk mal für eine Stunde ausfällt. Das ist nicht korrekt, denn der TFS unterstützt die Offline-Arbeit an den Sourcen. Dazu wird bei fehlender Netzwerkverbindung in den Offline-Modus geschaltet und sobald das Netzwerk wieder verfügbar ist, kann der Entwickler wieder Online gehen und bekommt eine automatische Übersicht, die ihm zeigt, ob es an den bearbeiteten Dateien auf dem Server in der Zwischenzeit Änderungen gegeben hat, die er gleich zusammenführen kann. Komfortabler geht es nicht.

Derek kritisiert auch, dass alles im Team Foundation Server gemacht werden müsse. Obwohl er seit mehreren Jahren den TFS nutzt und dennoch mehrmals im Text darauf hinweist, dass er dieses und jenes nicht wirklich kommentieren könne, da er sich damit nicht auskenne, kritisiert er trotzdem einige Punkte, zu denen ihm wohl noch gar nicht aufgefallen ist, dass er nicht weiss, wovon er spricht.

Das letzte Mal, als ich nachgeschaut habe, konnte ich die Quellcodeverwaltung aus

  • dem Windows Explorer heraus verwenden (mittels Shell Extension aus den TFS Powertools)
  • der Powershell Konsole heraus mittels Cmdlets steuern (ebenfalls mittels TFS Powertools)
  • der Kommandozeile heraus  benutzen (via tf.exe)
  • dem Team Explorer Everywhere sogar aus Eclipse heraus bedienen und
  • natürlich dem regulären Team Exporer heraus nutzen.

Es gibt bestimmt noch mehr. Da Microsoft ein SDK dazu zur Verfügung stellt, würde es mich zumindest nicht wundern.

Derek kritisiert auch, dass das Standard Merge Tool nicht seinen Ansprüchen genügt. Ehrlich gesagt, bin ich häufig ebenfalls nicht zufrieden mit dem Merge Tool. Es scheint genügend Entwickler gegeben zu haben, die das entsprechende Feedback geliefert haben, denn ein Microsoft Vögelchen hat mir gezwitschert, das es mit Visual Studio vNext etwas Besseres geben wird.

Und… wem ist es aufgefallen? Ich habe geschrieben Visual Studio vNext. nicht Team Foundation Server vNext. Compare & Merge finden nämlich auf dem Client statt. Das hat in erster Instanz nichts mit dem Team Foundation Server zu tun.

Vermutlich gibt es deshalb auch so viele alternative Möglichkeiten, Dateien miteinander zu vergleichen und Änderungen zu integrieren. Einige davon integrieren sich ziemlich gut in die UI vom Visual Studio wie z.B. Code Compare, während andere wie z.B. WinMerge extern und somit auch prima über die Explorer Shell arbeiten. Visual Studio macht es nämlich einfach möglich, anzugeben, mit welchem Tool man vergleichen und integrieren möchte. Hat Derek das etwa übersehen?

Diese Art der Kritik, die aus Halbwahrheiten besteht, um falsche Argumente zu untermauern, grenzt an Polemik. Dazu passt auch Dereks Aussage: Einige [Probleme] sind ziemlich erschreckend (wie z.B. verloren gegangene Checkins), ich persönlich bin ihnen aber noch nicht begegnet.”. Erinnerungen an Heise Posts und Reaktionen darauf (Don’t feed the Trolls) drängen sich dabei förmlich auf.

Bug Tracking

Die Überschrift selbst ist eigentlich schon verkehrt. Der Team Foundation Server beinhaltet kein Bug Tracking sondern ein Work Item Tracking. Einer der von Haus aus vorhandenen Work Item Typen nennt sich “Bug”. Man mag es nicht für möglich halten, aber sogar Entwickler finden manchmal Fehler. Darüber hinaus ist sich Microsoft der Tatsache bewusst, dass es viele existierende Lösungen gibt, die sich mit dem Thema Bug Tracking beschäftigen. Sobald ein Entwickler seine Kunden Fehler melden lässt muss daher unterschieden werden zwischen der externen und der internen Kommunikation.

Extern nutzen viele die unterschiedlichsten Lösungen (bis hin zu CRM Systemen, da es sich ja um Kundenkommunikation handelt). Intern wiederum geht es rein um die Kommunikation der Entwickler unter sich. Und der geneigte Leser wird mir zustimmen: Diese Kommunikation sollte i.d.R. nicht unbedingt öffentlich gemacht werden.

Dank der Tatsache, dass das Work Item Tracking genau wie alle anderen Services des Team Foundation Servers über sehr gut dokumentierte Webservices funktioniert, ist es daher meist möglich, externe Systeme anzubinden, um eine Brücke zwischen der Kundenkommunikation und der internen Entwicklerkommunikation (sprich: Status des Work Items) herzustellen.

Aber selbst wenn kein externes System zur Verfügung steht und der Entwickler überlegt, die Boardmittel für Kunden nutzbar zu machen, gibt es die Möglichkeit, Team Foundation Web Access im Work Item Only Modus bereitzustellen. Und wer denkt, ein Kunde wäre nicht in der Lage die vielen Felder auszufüllen, der passe bitte sehr den Work Item Typen einfach an.

Denn auch das scheint bisher noch niemand Derek erzählt zu haben: Work Item Typen, deren Aufbau, die Informationen, die sie aufnehmen und der Workflow dahinter lassen sich mittels Editor anpassen, selbst erstellen und beliebig integrieren. Ich weiß z.B. von der Existenz einer Microsoft CRM Erweiterung und auch einem Outlook Addin für eingehende (Bug-) Emails.

Project Management

Ich muss ehrlich gestehen, dass ich diesen Punkt nicht ganz verstanden habe. Das mag aber auch daran liegen, dass ich selbst die Möglichkeiten des Team Foundation Servers in diesem Kontext bisher eher stiefmütterlich behandelt habe.

Im Wesentlichen erklärt Derek hier, seine Projekt Managerin würde Excel als Tool bevorzugen, da es ihr besser gefalle als der TFS. Darüber hinaus weist er darauf hin, dass sich in der agilen Softwareentwicklung konstant der Entwicklungsprozess ändern würde und diese Tatsache nur unzureichend komfortabel vom TFS untersützt würde.

Gründsätzlich würde ich es anders formulieren. Wem die umfangreichen Möglichkeiten, Projekttemplates (aus meiner Sicht sehr wohl komfortabel) anzupassen und mit Standardmitteln Reports zu entwickeln und über die Analysis Services sowohl via Web als auch über beispielsweise Excel einfach zur Verfügung zu stellen, nicht ausreichen, der ist – wie Derek selbst sagt – ja nicht dazu gezwungen, den TFS zu benutzen.

Er vergisst allerdings auch die Möglichkeit zu erwähnen, zu einem Projekt Kickoff beispielsweise unglaublich komfortabel in der Lage zu sein, Work Items via Excel anzulegen oder basierend auf den erfassten Informationen und der Integration in z.B. Microsoft Project selbiges für eine standardisierte Projektverwaltung nutzen zu können.

Dass es das flexible System des TFS und der Erweiterungsmöglichkeiten erlaubt, beispielsweise auch Word anzubinden, eigene Ribbons zu gestalten und Vorlagen zu entwerfen, die direkt an Daten aus dem TFS gebunden werden können, erwähnt Derek auch mit keinem Wort. Übrigens auch nicht im später folgenden Absatz über Integration.

Build System

“TFS will build every checkin […]”. So fangen auch die meisten Produktwerbungen an. Fliegen macht Spaß, das Waschmittel wäscht weißer als alle anderen und mit diesem Mittel wird magisch jede Kruste in perfekten Glanz verwandelt.

Der Ehrenrettung halber sei erwähnt, dass Derek diese Aussage im folgenden Abschnitt einschränkt, darauf hinweist, dass diese Funktion lediglich eingeschaltet werden kann und dann die wirkliche Kritik äußert: Das Entwickeln eines benutzerdefinierten Build-Steps sei enorm aufwändig.

Was ich dann schon eher lustig finde, ist, dass viele andere Build Systeme sich damit brüsten, dass sie besonders einfach zu handhaben wären. Häufig kommen simple Scripte zum Einsatz. Wozu sollte man auch ein C# Projekt vom Start treten, wenn die Ausgabe lediglich gezippt werden muss.

Mal abgesehen davon, dass es eine schier endlose Zahl bereits fertiger Tasks gibt, die eine große Vielfalt an Themen mittels vorgefertigter Activities abbildet, lassen sich in eine Build Sequenz auch Skripte einbauen. Wozu also die Aufregung? Wer aber tatsächlich selber Activites entwickeln möchte (oder vielleicht sogar muss), der findet im Wissenskollektiv diverse Anlaufstellen, die einem die Basis dafür vermitteln. Hier z.B. die vollständigste und dabei gleichzeitig einfachste Einführung zum Thema Customizing Team Build 2010 von Ewald Hoffman.

Derek ist ebenfalls davon überzeugt, dass das TFS Build System nicht zur Continuous Integration tauge, da es eine Strong Pipeline benötige, was der TFS nicht biete. Was genau er damit meint,… diese Erkenntnis bleibt er dem Leser schuldig.

Dafür vergisst er aber gewohnt wiederkehrend, zu erwähnen, zu was das Build System des TFS noch alles zu gebrauchen ist. Weder scheint er zu wissen, dass es in der Lage ist, Unit Tests zu automatisieren, neue Work Items bei Build Fehlern anzulegen, die Build Ausgabe in virtuelle Testsysteme zu deployen, die Konfiguration des Builds komfortabel in einer konfigurierbaren Oberfläche anzubieten, private Builds zu erstellen, und und und. Und was die Agenten, die er nur im Nebensatz erwähnt, noch alles drauf haben, darauf geht Derek sowieso nicht ein (z.B. Tags).

Integration

Derek kritisiert hier im wesentlichen zwei Punkte.Zum einen, dass der TFS es nicht erlaube ein alternatives Versionierungssystem einzusetzen und zum anderen dass das Build System nicht ausgetauscht werden könne.

Da hat er natürlich vollkommen recht. Diese Praxis unter Produktherstellern ärgert mich auch zunehmend. Ich habe ebenfalls kein Verständnis dafür, dass Word nicht den Editor von Open Office verwenden kann, der Windows Explorer nicht unter Ubuntu verfügbar ist und wieso der integrierte Quellcode Editor im Visual Studio nicht durch VIM ersetzt werden kann entzieht sich auch meiner Kenntnis.

Aber aller Sarkasmus beiseite: Soweit ich weiss gibt es Plugins, um z.B. Hudson und Cruise Control.NET (beides beliebte Build Systeme) in den TFS zu integrieren (oder andersherum…).

Worum es hier aber wirklich geht ist natürlich die TFS Integration Tools. Diese sollen dazu dienen, zwischen veschiedenen Versionskontrollsystemen Daten auszutauschen und zu synchronisieren. Von Haus aus werden neben dem TFS 2010 und 2008 auch Adapter für Rational ClearCase und Rational ClearQuest mitgeliefert sowie ein Adapter für dateibasierte Versionskontrollsysteme. Mich erinnert das ein wenig an ein Strategiepapier von Joel Spolsky (“Let me go back!” Unbedingt lesen!)

Zusammenfassung

Es gibt noch diverse andere Punkte in Dereks Text, die schlicht falsch sind. Der Team Foundation Server zwingt einen nicht, Checkins mit Work Items zu verknüpfen. Aber man kann es sehr wohl optional einschalten (und selbst dann gibt es eine Override Checkbox). Es gibt auch keine strengen Vorlagen, denen man folgen muss. Aber es werden Vorlagen angeboten, die man benutzen kann und/oder beliebig seinen Vorstellungen anpassen. Alle Punkte, von denen Derek implizit in seiner Zusammenfassung behauptet, der TFS biete sie nicht an, sind im Gegenteil genau so entweder in der Basisinstallation vorhanden oder konfigurierbar.

Derek bevorzugt offensichtlich Produkte, die so wenig an Standards mitbringen, dass der Entwickler wirklich alles selbst einrichten, konfigurieren, erstellen, etc. muss und dabei gezwungen wird, im Prinzip zu erlernen, wie er grundsätzlich selbst ein ALM Werkzeug entwickelt. Er schreibt: “[…] the organization can trick itself into thinking that configuration management is a solved problem.”. Ganz klar ist das die Schuld des Team Foundation Servers.

Nein. Natürlich nicht. “This is not only TFS's fault, though.”.

Während ich seinen Punkt durchaus verstehe, fällt mir dabei natürlich der viel zitierte Spruch ein: “Don’t reinvent the wheel!”. Besser noch gefällt mir der Zusatz, den ich zuerst bei einem Kollegen von Joel gelesen habe: “[…] you shouldn't reinvent the wheel. Unless you plan on learning more about wheels, that is.” (Jeff Atwood, 2009).

Daher ist es auf jeden Fall besser, schneller und einfacher, alle Dienste, Anbindungen an Drittsysteme, Basiskonfigurationen (dazu gehören auch Linux Systeme und wie wir wissen, gibt es die ja in jeder Organisation), Versionskontrollen, Build-Systeme und das Projektmanagement aus bunten Puzzleteilen manuell selbst zusammenzubauen. Damit schließt sich der Kreis und Derekt hat eindrucksvoll unter Beweis gestellt, dass der Team Foundation Server in der Tat Entwicklungskapazitäten zerstört.

Q.E.D.

Zumindest, wenn es einem darum geht, etwas über ALM Werkzeuge zu lernen und weniger darum, Software effizient zu entwickeln.

Comments (1) -

Cbinder
Cbinder
9/14/2011 5:07:54 PM #

Danke für den Post!

Es ist schon schade, dass Derek, der vorgibt 3+ Jahre mit dem Tool zu arbeiten, diverse Dinge in 3 Jahren nicht verstanden hat..... Die von Dir erwähnten "renommierten Softwareentwickler und –Architekten" sind meist auch wenig konstruktiv in Ihrer Kritik. Einige der Kritikpunkte im Bereich Version Control sind durchaus berechtigt und schon lange bekannt. Da Developer Produktivität ein Schwerpunkt für TFS 11 ist, werden die meisten der angesprochenenen Punkte im Bereich Version Control behoben sein. Wer schon mal reinschauen möchte: blogs.msdn.com/.../...-improvements-in-tfs-11.aspx

Comments are closed

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS