| 

.NET C# Java Javascript Exception

0

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.

visual-studio tfs build versionskontrolle mercurial produktentwicklung
Schreibe einen Kommentar:
Themen:
produktentwicklung mercurial versionskontrolle build tfs visual-studio
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail
TOP TECHNOLOGIES CONSULTING GmbH