Wir sind gerade dabei, einen Source Control / Build / und einen weiteren Server für die .NET-Entwicklung einzurichten, und wir denken darüber nach, entweder den Team Foundation Server (der viel kostet) zu verwenden oder mehrere zu kombinieren Open-Source-Optionen wie SourceForge Enterprise / GForge und Subversion und CruiseControl.net und so weiter. Hat jemand die volle OSS-Straße hinuntergelaufen oder ist es TFS nur, wenn Sie es richtig machen wollen und bald zur Arbeit kommen?
Meine Arbeit verwendet zur Zeit einen OSS-Build-Prozess mit Cruise Control als Engine und es ist großartig. Ich würde vorschlagen, wenn Sie nicht wissen, warum Sie TFS benötigen, ist es wahrscheinlich nicht die Kosten wert.
Was Sie bei den OSS-Daten beachten müssen, ist, dass die Software entweder schon seit Jahren von der Java-Crew verwendet wird oder die Software ein Port mit ähnlichem Java-Code ist. Es ist robust und eignet sich für den Zweck.
Microsoft kann OSS-Code nicht liefern, weshalb sie viele Open-Source-Sachen neu implementieren müssen. Also, nein, es ist nicht notwendig, und es wurden Millionen von Projekten auf diesem Stapel verschifft. Die Kehrseite ist, dass es auch viele nette Funktionen gibt, die Sie mit TFS bekommen, die Sie (einfach) nicht mit dem OSS-Stack bekommen werden, wie die Integration mit Ihrer Bug- / Feature-Tracking-Software.
Ich bin immer den OSS-Weg gegangen und hatte nie ein Problem. Ich würde TeamCity auch sehr für Ihre CI-Lösung empfehlen. Es gibt eine kostenlose Lizenz und ich denke, dass CC.NET für eine einfache Konfiguration und Rückmeldung aus dem Wasser gerät.
Ich bin seit ungefähr 1,5 Jahren ein täglicher Benutzer von TFS.
Wenn Sie TFS verwenden, stellen Sie sicher, dass Sie VSTS2008SP1 installieren. Die überwiegende Mehrheit der Menschen, bei denen ich Beschwerden eingereicht habe, verwenden die Version 2005. 2005 ist das klassische "Microsoft 1.0" -Syndrom. Es gab eine Menge Probleme, die durch die 2 späteren "Versionen" behoben wurden.
Das Service Pack für 2008 ist nicht nur eine Fehlerbehebung, sondern hat viele neue Funktionen hinzugefügt.
Was die Wahl gegen OSS betrifft - es gibt viele Diskussionen (hier und anderswo). Es ist kein billiges Produkt - aber es ist die beste Wahl für viele Szenarien (und das Schlimmste für andere).
Wir haben uns TFS angeschaut, aber am Ende ging es mit Subversion + Trac + VisualSVN. Wir machen CI gerade nicht, aber Cruisecontrol wäre das, was wir verwenden würden, denke ich.
Ich habe Trac mit zahlreichen Open-Source-Projekten verwendet, und es ist großartig. Es ist wirklich nur ein Teil von dem, was TFS tut, also müssen Sie dort eine Entscheidung treffen - wenn Sie alles verwenden, macht TFS wahrscheinlich einen besseren Job, alles zusammen zu binden. Trac ist ein Wiki / Bug Tracker / Source Browser. Alles ist verlinkt - wenn Sie den Namen einer WikiPage eingeben oder "Fix Bug 1234" in einer Commit-Nachricht sagen, gehen die Links immer an die richtigen Stellen, wenn Sie diese Nachricht in Trac sehen. Es ist ein Werkzeug, das Ihnen hilft, Ihre Arbeit zu erledigen, aber im Allgemeinen nicht im Weg ist.
VisualSVN ist eine großartige Brücke zwischen TortoiseSVN (einem Subversion-Client) und VisualStudio und verbessert die Produktivität erheblich. Sie haben eine kostenlose Testversion, und es ist nicht sehr teuer im Nachhinein ($ 50 / Benutzer), aber es lohnt sich.
Ein möglicher Nachteil von Trac ist in einer Windows-Welt, es ist ein Schmerz, an IIS zu arbeiten. Ich habe Trac viele Male installiert, war aber schnell frustriert, um es richtig funktionieren zu lassen. Ich habe Apache auf einer anderen IP installiert (könnte auch einen anderen Port verwenden) und dann war es nahtlos.
Außer einer Person in meinem Team (die ein kleines bisschen Erfahrung hatte) hatte noch nie jemand Subversion benutzt. Ein Paar hatte VSS benutzt, und das ist alles. Jeder war ziemlich skeptisch, aber ich würde sagen, dass sie innerhalb weniger Tage alle Konvertiten waren. Nachdem ich Trac vollständig gelernt habe und sich an alles gewöhnt habe (ein paar Tage mehr), ist jeder total verkauft und liebt es.
Unser Unternehmen nutzt die CruiseControl / SVN / nAnt / JIRA-Kombination mit großem Erfolg.
Der Deal Breaker mit TFS ist, dass es sich nur für größere Unternehmen lohnt. Für kleine Unternehmen mit 30 oder weniger Entwicklern, die von der oben genannten Open-Source-Kombination schon sehr profitieren würden, wird es furchtbar teuer werden.
Der wirkliche Vorteil der Verwendung von TFS im Vergleich zu einem separaten Satz von OS-Tools ist die Integration der verschiedenen verfügbaren Informationsflüsse.
* Erstellen Sie eine Anforderung und fügen Sie sie in TFS ein
* Erstellen Sie eine Reihe von Aufgaben, verknüpfen Sie sie mit der Anforderung und weisen Sie sie den verschiedenen Entwicklern zu
* Jeder Entwickler arbeitet an seiner Aufgabe und checkt die Aufgabe dem in der Checkbox eingecheckten Änderungssatz zu
* Ein Bugfix kommt herein, auch in diesem Fall wird der Änderungssatz mit der Bugfix-Anfrage koordiniert und Sie können den Bugfix auch der ursprünglichen Anforderung zuordnen
Sobald dies erledigt ist, können alle Informationen verwendet werden, um das Projekt zu verfolgen und eine Bewertung über die Arbeit zu machen, wie zum Beispiel wie viele Änderungen eine Fehlerbehebung bewirkt hat, welche die Anforderung sind, die mehr Fehler oder Änderungsanfragen erzeugt hat und so weiter.
All diese Informationen sind sehr nützlich in mittleren und großen Organisationen und aus dem, was ich jetzt sehe, ist es nicht möglich (oder sehr schwierig), die Integration verschiedener OS-Tools zu verfolgen.
Der TFS-Stack ist weit mehr als die Quellcodeverwaltung und ein CI / nächtliches Build-Setup. Denken Sie an Projektmanagement, Fehlerberichte und alles zusammen ergibt etwas mehr als nur CruiseControl, SVN und NAnt. Nur die Berichte allein könnten die Investition wert sein. Und denken Sie auch daran, wenn Sie ein MSDN-Abonnent / ISV-Goldpartner / etc. Sie könnten etwas davon kostenlos bekommen ...
Ich habe erst vor kurzem damit begonnen, mit TFS zu arbeiten, und da ich von einem vorher offenen Quell-Stack gekommen bin, finde ich es ziemlich fehlend.
Während die Integration aller Bug- und Task-Tracking-Funktionen ein wirklich großartiges Feature ist, haben die Negative das Gewicht.
Persönlich verwende ich den folgenden Stapel, der mir alles gibt, was wir von der kontinuierlichen Integration bis zu automatisierten Bereitstellungen im Unternehmen zu einem Bruchteil der Kosten machen müssen:
Ich habe beide in Aktion gesehen (obwohl ich Java-Entwickler bin). Die Vorteile eines Pick & Mix-Ansatzes sind, dass Sie die besten Bits für alles auswählen können (zB würde ich Hudson für CI auschecken - es ist hervorragend für Java, funktioniert auch für .Net und hat Lasten von Plugins und ist wirklich einfach zu bedienen). Der Nachteil ist, dass Sie die gesamte Integration selbst durchführen müssen. Dies wird jedoch in der Java-Welt einfacher viel . Lassen Sie die Leute auch nicht sagen, dass ein unterstütztes Produkt besser ist. Bei vielen OSS-Produkten in diesem Bereich ist die Qualität ausgezeichnet und Sie erhalten besseren Support von der Cimmunity, statt auf eine Antwort aus dem Supportvertrag Ihres Herstellers zu warten (IBM, ich sehe Sie an)
>Hoffe, das hilft.
Ich stimme dem zu, dass es sich nur lohnt, TFS zu verwenden, wenn Sie genau wissen, wofür Sie es brauchen. Die OSS-basierten, billigen oder kostenlosen Add-Ins wie Visual SVN und TestDriven.Net sind so gut, dass die Integration mit VS bereits nahtlos ist.
Ich denke, dass sich das TFS für all die zusätzlichen Funktionen, die in den obigen Beiträgen erwähnt werden, lohnt. Es ist die kontinuierliche Build-Funktionalität, die wirklich fehlt, aber wir erweitern diesen Teil mit CruiseControl.NET, das ist großartig. Der einzige Grund, warum wir uns gegen TFS entscheiden würden, wenn wir es jetzt tun würden, ist, dass wir die Plattformentwicklung unserer Produkte übergreifen. Also, wenn Sie darüber nachgedacht haben, denken Sie OSS. Subversion / Trac wäre meine Lieblingskombination auf diese Art und Weise, wobei CruiseCONtrol.NET immer noch das Rückgrat ist. CC.NET mit Mono funktioniert gut unter Linux und Mac.
TFS2010 hat eine TFS Basic, die nichts kostet (über Ihre msdn Subscription / Visual Studio Lizenz hinaus). Es ist auf 1 pro VS-Lizenz beschränkt, aber Sie benötigen nur zusätzliche Lizenzen für Nicht-VS-Benutzer
Allein die UI-Automatisierung in VS2010 macht TFS zum Gewinner, wenn es darum geht, Open-Source-Lösungen zusammen zu stopfen
Es ist erwähnenswert, dass die beste Alternative zu einer breiten Palette von TFS-Funktionen nicht unbedingt OSS, sondern Low-Budget-Werbung, wie NDepend für Code-Qualität und Architektur-Exploration, NCover für Code-Coverage, TestDriven.NET zum Testen verschachtelter IDEs ...
Tags und Links tfs svn open-source cruisecontrol.net