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
Der TFS ist klasse

Meine gestrige Behauptung (im Beitrag Developement Infrastructure), den TFS klasse zu finden, stieß wohl auf einige Verwunderung:

Bjoern Rochel per Twitter:

Don't know what to think when I hear a dev say: "TFS is awesome". 2 me this feels like it is from a Fringe-esque parallel universe...

Auf meine Frage, was Björn den konkret am TFS schlecht findet erhielt ich folgende Punkte aufgezählt

  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.

Ein kleines Lob gab es von Björn immerhin:

Björn Rochel per Twitter

Ich find WorkItems und Reports darüber übrigens gar nicht schlecht. Leider vermiest der Rest mir das tägliche Arbeiten derart

Der wichtigste Kritikpunkt, der nicht nur von Björn genannt wurde, war der fehlende Offline-Support, bzw. die Tatsache, das es sich bei der Versionskontrolle des TFS um ein zentralisiertes System handelt und nicht um ein verteiltes System, wie z. B: das von Mercurial oder Git. Code kann mit dem TFS nicht lokal versioniert werden.

Zuerst…

… mal meine Sicht der obigen Kritikpunkte bevor ich schreibe, was ich am TFS so klasse finde:

  1. Kann ich innerhalb des Firmennetzes nicht nachvollziehen. Richtig ist, dass die Kommunikation des Team Explorers per Webservices stattfindet und über das Internet der SOAP-Overhead negativ spürbar ist. GetLatest ist dann allerdings IMO weniger langsam als alles was mit den Work Items zu tun hat.
  2. Ja, das ist ein Nachteil. Der gleiche Nachteil, den SVN mit den blöden .svn-Ordner hat
  3. Richtig, aber: In den meisten Produktentwicklungen die ich bisher gesehen habe, ist Feature-Branching kein Thema, auch da es isolierte Features voraussetzt. In Projekten die IMO in den meisten kleinen und mittleren Firmen entwickelt wird ist ein Feature mit der Anwendung verwebt. Die Entwicklung oder Änderung eines Features, setzt die Änderung des ganzen Produktes voraus. Das ist nicht schön, habe ich aber bisher – außer bei Projekten von Leuten die in der Community-Aktiv sind -  nicht anders erlebt.
  4. Richtig Offline Support gibt es nicht, da es wie gesagt, ein zentralisiertes System ist.
  5. Ehrlich gesagt, finde ich .gitignor nicht einfacher als der File Types Manager im TFS. .gitignore ist nur flexibler.
  6. Dem stimme ich 100%ig zu
  7. Ist es denn geschlossen? IMHO nein, allerdings wirkt es auf dem ersten Blick so. Der TFS lässt sich recht gut anpassen, erweitern und anprogrammieren. Wie alles bei MS ist das halt nicht gut Dokumentiert.
  8. Wie Punkt 7. wirkt es auf dem ersten Blick wirklich so. Aber wie ich gestern beschrieben habe, nutze ich weiterhin Hudson und MSBuild als Alternative zum Team Build.

DVCS vs. CVCS

Verteilte Versionskontrolsysteme (DVCS) haben selbstverständlich riesige Vorteile. Offline-Support und Feature-Branching wurden bereits genannt. Allerdings müssen die Vorteile auch erkannt, gekannt und akzeptiert werden. Die Arbeitsweise mit DVCS muss auch gelernt und verstanden werden.

Die Mehrheit der Entwickler kennen nur VSS, SVN, CVS und den TFS. Die Mehrheit der Manager sehen kein Vorteil, dass Ihr so wertvoller Sourcecode nicht zentral “kontrolliert” wird, sondern “unkontrolliert” auf unzähligen Repositories verteilt ist. Verteilte Systeme werden also – wenn nicht als Gefahr, dann doch - als zu Aufwendig und zu schwer zu kontrollieren angesehen.

In einem speziellen Fall wird es sogar als problematisch angesehen, dass die Softwareentwickler auf ihren eigenen Rechnern entwickel, statt in einer zentralisierten Entwicklungsumgebung ;-)

Verteilte Systeme sind im Firmenkontext noch nicht angekommen, bzw. auch nicht wichtig.

Aus dem Blickwinkel ist das zentralisierte System also kein Ausschlusskriterium des TFS für den Einsatz in einer Firma die Produktentwicklung macht.

Auch die verpfuschten das TFS-Binding in den Projektdateien ist kein Ausschlusskriterium, da der TFS für die Produktentwicklung in der Regel für längere Zeit eingesetzt wird, das System für alle Entwickler vorgeschrieben wird. Einmal eingerichtet, ist das TFS-Binding also kein Thema mehr.

Alle Entwickler haben mit dem gleichen Prozess und dem gleichen System zu arbeiten.

Nebenbei:

Ich schreibe hier aus der Sicht der Produktentwicklung, die länger als nur ein, zwei Jahre betrieben wird. Produktentwicklung kann auch mehr als 15 Jahre gehen, wie es bei meinem letzten Arbeitgeber der Fall war.

Projektarbeit und die Arbeit an Open Source Projekten ist kurzlebiger, hier wirkt sich ein starres System mit festen Prozessen negativer aus, als in der Produktentwicklung. Bei der Projektarbeit wechselt das Team eher als bei der Produktentwicklung. Im letzteren wechseln zwar vereinzelte Team.-Mitglieder, aber es ist dennoch immer über Jahre das Softwareentwicklungsteam.

Warum der TFS klasse ist:

Der TFS ist aufwendig einzurichten. Wenngleich die Installation und die Grundkonfiguration mit der 2010er Version so leicht wie die Installation des Visual Studio 2010 ist, kann es dennoch eine Woche oder mehr gehen, bis der TFS an die vorhandenen Prozesse angepasst ist. Die beiden vordefinierten Prozesse sind wohl in den seltensten Fällen einsetzbar.

Der TFS ist deswegen klasse, weil er nicht nur Versionskontrolle ist. Die große Stärke ist aus meiner Sicht, dass die Work Items stark mit der Versionskontrolle Verknüpft sind.

Hätte ich eine so starke Verknüpfung mit Mercurial und einem entsprechenden anderen Bug-Tracking, würde ich sofort dieses empfehlen. Auch wenn der Schulungs- und Akzeptanzaufwand für verteilte Versionskontrollen sehr hoch sein könnte .

Mit Kiln habe ich schon eine sehr starke Kombination, aber so intuitiv und so komfortabel wie im TFS ist es noch nicht.

Der TFS ist deswegen klasse, weil ich über die Work Items sofort sehen kann, welcher Code geändert worden ist. (Ja, das geht mit anderen Systemen auch) Der TFS ist klasse, weil ich in jeder Zeile Code sehen kann aus welchem Grund sie erzeugt oder geändert worden ist. Die Work Items sind klasse. Und der definierbare Prozess hinter den einzelnen Work Items ist klasse. Klasse ist auch, dass die Work Items von Leuten bedient werden können, die mit Web-GUIs nicht so zurecht kommen. Als Entwickler finde ich den TFS klasse, das Versionskontrolle und Work Items im Visual Studio integriert ist, das ich alles in einer Umgebung kompakt beisammen habe.

Wenn ich mich also in einer Umgebung befinde, die nicht der Firma FogCreek Software entspricht und dem entgegen einem Abbild von Roland Weigelts Community Pyramide entspricht, ist der TFS ideal: Einfach zu bedienen, einfach zu verstehen, feste Prozesse und alles ist integriert.

Community Pyramide:

Auf der dotnet Cologne 2010 zeigte Roland Weigelt in der Keynote eine Pyramide mit Softwareentwicklern, an deren Spitze sich diejenigen Entwickler befinden, die aktiv an der .NET-Community teilnehmen. Das sind zumindest auch diejenigen die auch den Begriff ALT.NET irgendwo mal gelesen haben. ;-)

Ich möchte die anderen Systeme nicht schlecht machen, …

…ganz im Gegenteil, aber ich sage auch nicht, dass der TFS generell auf keinen Fall genutzt werden sollte. Im Gegenteil sollte der TFS auch immer ernsthaft in Betracht gezogen werden. Nicht nur die Versionskontrolle ist wichtig, sondern auch das drum herum und abhängige Infrastruktur und die Leute die es nutzen sollen.

Ich verstehe, warum Björn, Stefan Lieser, Golo Roden und Ilker Cetinkaya den TFS ablehnen. Ich verstehe, warum DVCS als so wichtig angesehen werden.

Wie bereits geschrieben, nutze ich privat Mercurial und finde ihn und die Arbeit mit ihm ebenfalls absolut klasse.

Würde ich eine Versionskontrolle in einer Umgebung einführen, in der es nur Softwareentwickler gibt, hätte ich mich bei meinem Arbeitgeber möglicherweise nicht so schnell für den TFS entschieden. Aber bei der Produktentwicklung hängt noch etwas mehr dran als nur das schreiben von Code und dessen Versionierung: Supportabteilung, Testabteilung, Produktmanager. Klasse ist, dass man mit dem TFS alle schnell integrieren kann. Der Schulungsaufwand für alle beteiligten ist ebenfalls fast null.

Und Team Build?

Hierzu schreibe ich demnächst mehr in einem weiteren Beitrag.

DotNetKicks-DE Image
Posted: Sonntag, 20. März 2011 08:54 von Jürgen Gutsch

Kommentare

dotnet-kicks.de sagte:

Sie wurden gekickt (eine gute Sache) - Trackback von dotnet-kicks.de

# März 20, 2011 10:14

mh2011 sagte:

Ich bin Imme skeptisch, wenn jemand absolute Wahrheiten zu haben glaubt. TFS passt nicht überall und für jeden, genauso wenig wie Mercurial, svn oder git. Deshalb sollte niemand TFS oder andere Systeme kategorisch ablehnen.

Aus eigener Erfahrung (wir machen Produktentwicklung und benutzen TFS seit es die erste Go-Live-Lizenz der ersten Version gab), wird TFS erst dann richtig nützlich, wenn man die Integrationsmöglichkeiten nutzt. Wir hatten vorher Sourcesafe, was die initiale Motivation für die Suche nach was besserem war. Inzwischen möchten wir die Verzahnung zwischen SourceControl, Build, Workitems und Reporting nicht mehr missen.

# März 20, 2011 12:31

BjRo sagte:

Hi Jürgen,

Danke das Du die Mühe gemacht hast Deine Gedanken zu dem Thema zu bloggen.

Kritik in 140 Zeichen zu packen ist immer schwer. Twitter ist dafür einfach kein geeignetes Medium. Hättest mal vorher sagen müssen, das Du das für Deinen Post verwenden möchtest. Dann hätte ich wahrscheinlich ein ausführlicheres Medium gewählt. Ach ja, der Vollständigkeit halber sollten die fehlenden zwei Tweets auch rein ;-)

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 ;-)

Aber lass uns erst mal auf die Entwickler konzentrieren. Den da liegt tatsächlich der Hund begraben, warum sich einige von uns nicht (mehr) mit dem TFS anfreunden können: Im Vergleich zu den Alternativen ist dort der TFS einfach zu starr und behäbig. Ich schaue Dich an, liebe TFS Versionskontrolle.

Feature-Branching und Micro-Commit-Workflows spielen Deiner Meinung nach im täglichen Arbeiten mit einem VCS eher keine Rolle. Ich sehe das ehrlich gesagt etwas anders.  Für mich ermöglichen diese Features eine ganz andere Arbeitsweise. Die lokale Zeitmaschine, wie Ralf Westphal sie genannt hat, ist für mich ein Werkzeug geworden, das ich nicht mehr missen möchte.

Aber lassen wir Zeitmaschine mal für nen Moment raus. Hast Du schon mal in nem Mainline-Ansatz mit Branches gearbeitet? Simplifiziert könnte das Beispielsweise folgendes heißen:

- Keine Entwicklung auf dem Master / Trunk mehr. Da wird nur noch integriert und released (Für Integration ist aber auch ein eigener Branch gängige Praxis).

- Nur ganze Features wandern in den Integrations-/Release-Branch.

Das ist eigentlich gängige und gute Praxis bei vielen großen Unternehmen, die den TFS einsetzen. Leider macht sie mit dem TFS aber auch mal so gar keinen Spaß, weil sie 2 Dinge in höherer Frequenz benutzt in denen der TFS (auch im Vergleich zu SVN) beispielsweise EINFACH NICHT GUT IST: Mergen und Branchen.

Wenn man mal das erste mal in einem DVCS gebranched und gemerged, dann wird einem erst bewusst wie weit ab vom Schuss die Versionskontrolle des TFS in diesem Modell ist. Oder anders herum wird einem bewusst warum 2011 immer noch Trunk + Branch per Release die am weitesten verbreiteste Branch-Organisation in der TFS Welt ist.

Zum Thema geschlossenes System. Natürlich kannst Du Teamcity durch Hudson ablösen. Kannst Du aber auch die Versionskontrolle austauschen? Den Kern der täglichen Arbeit mit dem TFS? Das geht leider nicht ;-(

Genauso wenig, wie Du MS eigenen Unittest-Runner ohne Zusatztools in der IDE austauschen kannst, aber naja das ist eine Geschichte für sich.

Wie Du ja schon richtig wiedergegeben hast find ich WorkItems gut. Allerdings sind sie für mich auch keine Lebensnotwendigkeit. Viele Dinge lassen sich gut und pragmatisch auch anders regeln.

So, soviel zum Thema Versionskontrolle. Mehr gibt’s dann beim nächsten Post zum Thema Team-Builds ;-)

VG

Björn

# März 20, 2011 12:36

Jürgen Gutsch sagte:

Hi Björn,

stimmt, hätte Dir sagen sollen, dass ich die Tweets zitiere. Bitte entschuldige das. Ich werde zudem versuchen die anderen Tweets zu ergänzen, bzw. ich wollte eigentlich nicht so konkret auf deine Anmerkungen eingehen, sondern sie sollte nur Anstoß für diesen Beitrag geben.

Danke auf jeden Fall für deinen ausführlichen Kommentar. Deine Beschreibung ist absolut verständlich und nachvollziehbar :-) Dem gibt es auch nichts entgegen zu setzen.

Der TFS ist für die Situationen in die ich bisher geraten bin die bestmögliche Lösung, wenn ich eben nicht nur die Entwickler betrachte, sondern auch alles was außenherum ist.

Wie es in dem Beitrag bereits richtig herausgelesen wurde, enthält er nicht nur Pros, bzw. die Pros sind hauptsächlich Politik. Klar lässt sich die Integration nicht Entwickler auch anders lösen, aber manchmal muss es schnell gehen. Und wenn es durch die Integration des TFS nicht schlechter wird, sondern besser, bringt es keinen Nachteil, sondern ist ein Schritt in die richtige Richtung. Es ist ja nicht so, dass man sich mit dem TFS den Weg in die Zukunft verbaut.

Selbstverständlich kann man auch die Versionskontrolle austauschen, indem Man anfängt einen Mercurial-Adapter (à la CodePlex) auf den TFS zu setzen setzen. Dann hat jeder Entwickler schon seine kleine "lokale Zeitmaschine". Das ist alles machbar. Am Ende kann man den TFS dann ganz abschalten ;-)

Was ich aber eigentlich generell sagen will:

Es gibt Situationen, in denen der TFS die besst mögliche Lösung ist. Das es irgendwann immer eine noch bessere Lösung gibt ist nur logisch. Aber den TFS von vornherein auszuschließen ist aus meiner bescheidenen Sicht falsch

# März 20, 2011 13:03

Jürgen Gutsch sagte:

Hallo mh2011,

vielen dank für deinen Kommentar :-)

Zu deinem ersten Absatz: absolut richtig. Zum zweiten Absatz: Klar wenn es passt und alles läuft ist es erstmal völlig in Ordnung.

# März 20, 2011 13:09

BjRo sagte:

Nur um sicher zu sein: Meinst Du Mercurial plus der TFS Versionskontrolle  oder Mercurial statt der TFS Versionskontrolle zu nutzen? Falls Du tatsächlich das Zweite meinst, wäre ich an weiterführenden Links interessiert ;-)

# März 20, 2011 15:32

Jürgen Gutsch sagte:

Hallo Björn, ich meinte im ersten Schritt ersteres (wie auf Codeplex). Der zweite Schritt (letzteres) wäre dann wohl eher Mercurial mit der Integration des TFS. J.

# März 20, 2011 16:03

Jürgen Gutsch sagte:

Meine .NET-Infrastruktur wird immer besser. Das ist ein subjektiver Eindruck. Aber der zählt wenn es

# Februar 26, 2014 08:00
Anonyme Kommentare sind nicht zugelassen