Team Foundation Build oder Teamcity?

Question

Wir sind ein hauptsächlich MS -Shop bei der Arbeit, die .NET -LOB -Entwicklung durchführen. Wir verwenden auch MS Dynamics für unsere CRM -App ... alle Entwickler verwenden derzeit VS/SQL Server 2008. Wir verwenden auch VSS, aber jeder hasst es bei der Arbeit und das ist schnell auf dem Weg nach draußen.

Wir beginnen unsere Initiative für die TDD -Implementierung im gesamten Team (~ Dutzend PPL). Ich habe TeamCity-Setup erhalten und meine ersten automatisierten Builds mit dem SLN Builder von 2008 ausführen und auch SVN mithilfe eines Kollegen eingerichtet haben, das die Quellensteuerungsanalyse durchführt. Ich denke, sie haben angefangen, mich in mein Schlangenöl einzukaufen, und warf die Vorschläge, TFs zu schauen.

Dies warf einen Schraubenschlüssel in das, was ich für unsere TDD -Architektur geplant hatte. In einer guten Weise, weil ich immer angenommen hatte, dass TFS für unser Team einfach zu teuer war und es nicht wert war (und ich habe dasselbe in anderen Geschäften gesehen, in denen ich gearbeitet / kenne). Ich habe das Gefühl, MS ist Jahre im TDD/CI -Gebiet hinter sich und dass die Produkte von Drittanbietern wahrscheinlich viel besser und reifer waren ... Ich muss noch viel recherchieren, aber ich dachte, ich würde hierher kommen, um zu sehen Wenn jemand tatsächlich beide Systeme verwendet hat.

Mir ist klar, dass die TFS viel mehr als nur einen Build -Server umfasst ... aber ich wollte dies nicht zumindest absichtlich zu breit machen. Was sind die praktischen Voraussetzungen bei der Verwendung von TFS/TFB anstelle von Teamcity - z. B. welche Vorteile würden wir verlieren/gewinnen? Hat hier jemand beide Systeme (TFS für TDD/CI und TeamCity/SVN) verwendet und kann vom praktischen Standpunkt aus sprechen?

Ich habe einige gesucht zu diesem Thema und einen Beitrag, den ich hier gefunden habe, erwähnte, dass die Nachteile von TFB nur MSBuild unterstützt haben. Ich hatte vor, Finalbuilder mit TeamCity zu verwenden. Und es scheint auch TFs zu unterstützen ...

Vielen Dank für einen Rat

Bearbeiten: Hat jemand TFs als Build/CI -Server verwendet und kann Erfolgs-/Fehlergeschichten erzählen?

Answer 1

Wir sind ein kleiner Entwicklungsgeschäft und entschieden, dass Team Foundation Server zu viel Overhead für uns trägt. Früher haben wir benutzerdefinierte MSBuild -Skripte geschrieben, um aus der Befehlszeile auszufahren, aber nachdem wir TeamCity entdeckt haben, haben wir unseren gesamten Build -Prozess auf sie verschoben.

Wir haben festgestellt, dass TeamCity einfach zu verwenden und zu konfigurieren ist, und JetBrains bietet hervorragende Unterstützung und Dokumentation. Sie sind auch in einem viel schnelleren Veröffentlichungs- und Update -Zyklus als Microsoft.

Ihre Unterstützung für die SVN -Quellenkontrolle ist ausgezeichnet, und wir mögen die Tatsache, dass sie sowohl MSTEST als auch NUNIT für Unit -Tests unterstützen.

Es hat uns auch gefallen, dass die TeamCity Professional Edition kostenlos war, sodass wir sie bewerten konnten, um zu sehen, ob sie für uns funktioniert hat. Wir haben die Anzahl der Projektkonfigurationen (20) nicht erreicht, bei denen wir auf die Enterprise Edition aktualisieren müssen.

Answer 2

Diese Frage Hat viele gute Antworten auf Teamcity. Es ist nicht mit TFS verglichen, aber es könnte ein Licht in die TeamCity für Sie werfen.

Ich habe beide benutzt und hatte Erfolg mit beiden, aber TeamCity war so viel einfacher. TeamCity war ein Kinderspiel, um sich einzurichten und zu konfigurieren. TFS war nicht. TeamCity ist felsig, es ist leicht zu warten und es funktioniert einfach einfach. Die Entwickler von Jetbrains haben großartige Arbeit geleistet, um auf die Community zu reagieren. Sie erhalten alle 6 bis 8 Monate eine Veröffentlichung, die einen echten Wert verleiht. TFS befindet sich in einem 2 -Jahres -Zyklus.

TeamCity bietet Ihnen mehr Auswahl, wie Sie erstellen und welche Quellvertretung Sie verwenden. Es ist nicht alles in einem, aber das ist manchmal eine gute Sache. Es hat auch eine gute Reihe von Erweiterungspunkten. Wir waren auch sehr zufrieden mit dem Agentenmodell, das es hat.

Ich habe 3 absolut Schmerzmittel in Teamcity durchlaufen. Das One TFS -Upgrade, das wir 3 Tage lang unsere Build- und Quellenkontrolle durchgeführt haben. Ich bin der Administrator für TeamCity in unserem Projekt und es dauert ein paar Stunden im Monat. TFS dauerte ein paar Tage in der Woche.

TeamCity + SVN + VisualSVN war die glatteste Umgebung, in der ich je gearbeitet habe. TFS war am Tag zu Tag im Allgemeinen glatt, aber nur, wenn jemand dort läuft.

Ich hoffe, das hilft

Answer 3

Die Vorteile von TFs sind eine integrierte Umgebung, die von Microsoft unterstützt wird. Ich persönlich mag TFS für die Quellvertretung nicht und habe eine Reihe von Problemen damit. Es ist klobig, hatte jedoch den Vorteil, dass VS -Integration (was auch in VisualSVN erhältlich ist, aber nicht so robust ist).

Persönlich denke ich, dass Sie SVN/TeamCity viel besser machen würden. Es ist einfach einfacher zu arbeiten und verhält sich mehr, wie Sie es erwarten würden. Wie bei den meisten Open -Source -Software entwickeln sich beide ständig weiter und haben immer die neueste und größte Funktion vor Microsoft. Die Integration zwischen den 2 ist wirklich gut und ich habe keine fatalen Mängel im System gefunden. Ich drängte ständig darauf, diese Route in meiner aktuellen Firma zu gehen (wir verwenden TFS), da ich glaube, dass es ein viel besserer Workflow ist. Als zusätzlichen Vorteil ist es deutlich billiger als die TFS -Route.

Ich habe auch Finalbuilder mit TFS verwendet - meine Frage dort ist, was Sie wirklich mit Finalbuilder kaufen, das Sie mit Nant/MSBuild nicht tun können. Die Antwort in meinem Geschäft ist leider sehr wenig IMO.

Answer 4

Zunächst einmal sehen Sie diesen Beitrag:

SVN vs. Team Foundation Server

In Bezug auf Ihre Frage, welche Umgebung TDD besser fördert, und dergleichen, meine zwei Cents ist, dass das Build -Management -System viel weniger wichtig ist als in der Build -Datei selbst. Ihre Ant- oder MSBuild -Datei sollte die Ziele haben, die Ihre Tests durchführen. Mit MSBUILD oder ANT müssen Sie keine MS -Testsuite verwenden. Sie können immer noch Nunit oder was auch immer Sie wollen. Das heißt, es spielt keine Rolle, ob TFS Ihre MSBUILD -Datei anruft oder ob CruiseControl ist oder ob TeamCity ist. Die Smarts befinden sich alle in der Build -Datei und in den Tools, die Sie in sie integrieren.

Meine persönliche Entscheidung ist es nicht, in die Art und Weise von TFS eingeschlossen zu werden, um Dinge zu tun, da Sie mit den Open-Source-Test-Tools, die es da draußen gibt, viel mehr Freiheit für viel weniger Kosten haben. TFS wird auch ein großes Upgrade erhalten. Wenn Sie mit TFS gehen möchten, ist es mein Rat, zumindest zu warten, bis 2010 veröffentlicht wird. Konzentrieren Sie sich darauf, Ihre MSBuild -Dateien so gut wie möglich zu gestalten.

Davon abgesehen muss ich zugeben, dass TFS eines der schönsten Bausysteme da draußen hat (2005 war schrecklich, 2008 war schön). Es war ziemlich cool, Benachrichtigungen und den Veröffentlichungsprozess in .NET -Code einfach anzupassen - Sie hatten viel mehr zentraler Kontrolle über die Build- und Release -Richtlinie als mit cruiseControl.net.

Also habe ich TFS und SVN/CCNET verwendet. Ich kann nicht viel mit Teamcity sprechen. Aber ein Build -Management -System sollte ziemlich agnostisch für das, was gebaut wird und wie es gebaut wird, ziemlich agnostisch sein. Für uns war die zusätzliche Kontrolle im Release -Management -Prozess, den TFS uns brachte, für uns einfach nicht ausreichend, um die stark verstärkte Verwaltungsanstrengungen einer vollständig integrierten TFS -Lösung zu rechtfertigen. Es war auch nicht ausreichend, die zusätzlichen pro Lizenzkosten von TFs zu rechtfertigen, was erheblich sein kann.

Answer 5

Der alte TFS Build war XAML -basiert und sehr umständlich und nicht schön zu arbeiten. Das neue TFS 2015 -Build -System ist jedoch besser und basiert auf vielen Webhaken und Integrationen von Drittanbietern. Sehr ähnlich zu Team City. Außerdem unterstützt TFS jetzt Git, sodass Sie nicht mehr auf die Verwendung der Team Foundation Version Control (TFVC) beschränkt sind. Mit TFS können Sie auch Ihre eigene On-Prem-Installation verwenden oder eine gehostete Lösung über visualstudio.com nutzen. TFS ist großartig, da es sich um eine vollständig integrierte Umgebung handelt (Arbeitselemente, Planung, Builds, Tests, Bereitstellungen), während Team City nur eine Baulösung ist. Als diese Frage ursprünglich im Jahr 2010 gestellt wurde, hätte ich Team City zweifellos empfohlen. Jetzt sind die 2 jedoch sehr wettbewerbsfähig. Ich würde sagen, dass es vielleicht auf eine All-in-One-Lösung hinausgehen würde, dann gehen Sie mit TFS, aber wenn Sie nur ein Build-System suchen, dann Team City.

Answer 6

Vergleich von Teamcity mit Visual Studio Team Services (dem neuesten Cloud-basierten Angebot von Microsoft):

• Beide eignen sich hervorragend für die Implementierung eines kontinuierlichen Integrationsprozesses

• TeamCity ist reifer und alles funktioniert einfach.

• Visual Studio Team Services dagegen entwickelt sich ständig weiter, um TeamCity zu treffen, und einige Dinge funktionieren einfach nicht gut (z. B. versuchen Sie, Builds zu lösen, die auf Pfaden mit Änderungen von Git ausgelöst werden. Die Dokumentation ist schwach und die Funktion selbst funktioniert einfach nicht (ab August 2016))

• Visual Studio Team Services erleichtert einfach, dass nur Cloud-basierte Agenten Ihren Build ausführen (der Nachteil ist jedoch, dass jedes für jeden Build eine saubere Ziehung Ihres Repositorys durchführen muss, was möglicherweise eine Minute oder mehr zum Build erhöht). Beide können auch lokale Build -Agenten unterstützen, die das Arbeitsverzeichnis für jeden frischen Build nicht abwischen müssen.

In beiden Fällen würde ich Ihnen jedoch sehr empfehlen, sich auch Cakebuild anzusehen, das die meisten Konfigurationsinformationen über bewegt wie Um einen Build aus dem CI -System und in C# -Codes zu erstellen, der zusammen mit allen anderen Quellcode in Ihrem Git -Repository liegt. Mit Cakebuild können Sie den gleichen Build lokal ausführen, wie Sie im CI -System ausführen. Wenn Sie einen Monat zurückgehen müssen, um eine bestimmte Version zu erstellen, verfügen Sie über den Quellcode und das Build -Skript, um dies zu tun.

Mit Cakebuild können Sie jetzt leicht zwischen TeamCity- und Visual Studio -Teamdiensten wechseln.

Der einzige Nachteil von Cakebuild ist, dass alle Ihre Build -Schritte in einer einzigen Aufgabe im CI -System gebündelt werden, die die Berichterstattung etwas weniger schön macht und möglicherweise zusätzliche Arbeiten beinhaltet, um die Testergebnisse in ein Format zu verwandeln, das das CI -Berichtssystem verwenden kann.

Answer 7

MS ist Jahre im TDD/CI -Gebiet hinter sich

Als einer, der seit 4 Jahren tddd ist, haben Sie Recht. MS fördert es noch nicht einmal und bieten noch Tools an, die gut mit dem TDD -Fluss funktionieren.

Bleiben Sie nicht mit Visual Studio für irgendeine Art von Automatisierung, Quellensteuerung oder agiler Workflow -Periode fest (hören Sie bitte auf TFS auf !!). Das Zeug, obwohl sie sagen, "neu" ist monolithisch und hat immer seltsame Probleme und Blähungen. Es ist immer schmerzhaft.

Ich habe Team City verwendet und es ist einfach erstaunlich, die Dinge funktionieren, es ist für die Benutzerfreundlichkeit ausgelegt und es ist einfach gut gestaltet und kompatibel mit den meisten Testwerkzeugen usw. Fine Nutze Visual Studio für Code, nichts anderes. Suchen Sie nach externen und Open -Source -Tools, um einen besseren CI zu erstellen. Der Verkauf "Sie können alles richtig machen" verkauft sich nicht und es funktioniert nicht. Die heutigen Menschen werden es gewohnt, verschiedene Werkzeuge von außen zu kombinieren, um Dinge zu erledigen. Es ist einfach nicht der richtige Weg, IMO für .NET zu betrachten. Frau verkauft gerne "Hey, du kannst einfach hier alles machen". Aber am Ende haben Sie nur Schmerzen, wenn Sie diese Route gehen und ihre Koolade (TFS, MS Fakes usw.) trinken.

Wenn Sie vorhaben, TDD zu machen, möchten Sie nicht alle MS -Tools verwenden. Sie werden entweder "ihren Weg" abgeschoben, Dinge zu tun, die oft proprietär und/oder aufgebläht sind, wenn Sie versuchen, mit ihren Werkzeugen zu tdd oder völlig restriktiv zu sein. Für TDD müssen Sie in der Lage sein, etwas Flexibilität und Auswahlmöglichkeiten zu haben, wenn Sie sich entscheiden, verschiedene Test -Frameworks, Assertion -Bibliotheken usw. zu entfernen.

Hinzufügen Krake Zusätzlich zu Team City, und es ist herausragend ... Sie werden sich einfach als Entwickler oder für alle, die DevOps machen, in ihn verlieben.

Hören Sie auf, sich auf Microsofts zu verlassen, um bei agilen Toolangeboten einen fortgesetzten Fehler zu erhalten

Schauen Sie aus dem Tellerrand und probieren Sie neue Dinge aus.