Cruise Control .Net vs Team Foundation Build

Question

Unser Team baut nächtliche und kontinuierliche Integrations-Builds auf. Wir besitzen Team Foundation Server und können Team Foundation Build verwenden. Ich bin mit CC.Net vertrauter und lehne mich so an, aber das Management sieht das gesamte für TFS ausgegebene Geld und möchte es nutzen.

Einige Dinge, die ich an CC.Net besser finde, sind die Flexibilität von Benachrichtigungen sowie die einfache Implementierung von benutzerdefinierten Skripts.

Wenn Sie Erfahrung mit beiden Produkten haben, welche bevorzugen Sie und warum?

Answer 1

Ich habe beide verwendet. Ich denke, es hängt davon ab, was Ihre Organisation schätzt.

Da Sie mit CC Net vertraut sind, werde ich nicht viel dazu sagen. Du weißt schon, was es cool macht.

Hier ist, was Ich mag über Team Foundation Build:

• Build-Agents. Es ist sehr einfach, jede Box in eine Build-Maschine zu verwandeln und darauf aufzubauen. MSFT hat das richtig gemacht.
• Berichterstattung. Alle relevanten Build-Ergebnisse (einschließlich Test) werden in einer SQL-Datenbank gespeichert und über SQL Server Reporting Services gemeldet. Dies ist ein immens leistungsstarkes Tool zum Erstellen von Build- und Testergebnissen im Zeitverlauf. In CC Net ist dies nicht integriert.
• Sie können ähnliche Anpassungen über MSBUILD vornehmen. Es ist im Grunde das gleiche wie mit NAnt mit CC Net

Hier ist, was mich treibt die Wand über Team Foundation Build up:

• zu C++/CLI-Projekte (oder führen Sie Unit-Tests zu bauen ... ?) Der Build Agent muss VSTS Dev oder Team Suite installiert haben. Das, Freunde, ist einfach nur verrückt.
• Es muss die TFS Mothership

angeschlossen werden, wenn Sie in einer großen org mit vielen Chefs sind die großen Budgets und Liebe Berichte (und tun Sie mich nicht falsch, hat dieser großen Wert) ODER Sie müssen auf eine Buildfarm mit mehreren Computern skalieren, ich würde Team Foundation Build bevorzugen.

Wenn Sie ein schlankerer Shop sind, bleiben Sie bei CC Net und erweitern Sie Ihre eigenen Reporting-Lösungen. Das haben wir gemacht.

Bis wir erworben wurden. Und habe TFS: P

Answer 2

Wir verwenden CruiseControl.net seit Juni '07 und es hat gut für uns gearbeitet. Der beste Teil, es integriert sich leicht zu SVN, das ist ein weit überlegener Anbieter von Quellcodeverwaltung.

So unser Setup ist:

• Cruise Control.Net
• SVN
• Trac - für Fehlerberichte und Projektmanagement (integriert sich perfekt mit SVN)
• nunit - für Unit-Tests

Wir hatten einige große parallele Entwicklung und die Verzweigung ein nd merging Erfahrung war spektakulär. Wenn Sie die Wahl haben, würde ich mit der obigen Konfiguration gehen!

Answer 3

Ich gehe davon aus, dass, wie Sie TFS besitzen, Sie es für die Versionskontrolle verwenden werden. In diesem Fall würde ich mich zu Team Foundation Build neigen. Das stimmt, ich stimme ziemlich gut mit Nick überein.

Ich schrieb die CruiseControl.NET integration for TFS. Es funktioniert gut und gibt Ihnen die gleichen Build-Funktionen, die Sie gewohnt sind. Für mich liegt der Hauptvorteil von CC.NET darin, dass es vollständig erweiterbar ist und Integrationen mit allen wichtigen SCM- und Build-Systemen unter der Sonne bietet. Der Hauptgrund, warum ich die CC.NET-Integration in TFS geschrieben habe, ist, dass in TFS2005 das Build-System keine Out-of-Box-CI-Unterstützung hatte. Die TFS2008-Version wurde jedoch stark verbessert und das Team wird es weiterhin sehr aktiv für zukünftige Versionen von TFS verbessern.

Der Hauptgrund für den Wechsel zu TFS Build ist, dass die Build-Informationen automatisch in TFS zurückgemeldet werden, um das Softwareentwicklungsbild hinsichtlich der Berichterstellung zu vervollständigen. Es lässt sich auch gut mit der Arbeitselement-Tracking-Seite von TFS und innerhalb der IDE (sowohl in Visual Studio als auch in Eclipse) integrieren.

Das heißt, wenn Sie große Investitionen in Nant-Skripte, die mehr als nur kompilieren und testen Sie Ihren Code haben oder Sie bereits eine selbst erstellte Reporting-Lösung haben, möchten Sie vielleicht bei dem, was Sie haben.

Answer 4

Der eigentliche Wert in Team Foundation Build besteht darin, dass Änderungssets und Arbeitselemente mit Builds verknüpft werden.

Dies ein paar nützlicher Szenarien ermöglicht:

• Sie bei einem Workitem schauen und herausfinden, was baut es in
• enthalten ist, Sie bei einem Build aussehen können und welche Änderungen am Code sehen (und Arbeitselemente) enthält es

Dann natürlich gibt es die Berichte über diese Informationen gebaut. Aber selbst diese Links eignen sich für Nicht-Management-Typen.

Werfen Sie einen Blick auf www.tfsbuild.com für "Rezepte" in verschiedenen Team Build-Konfigurationen.

Answer 5

SVN ist ein OK-Werkzeug weit überlegen ist nicht wahr, SVN vs TFS ist vergleichbar mit einem Ford Pickup vs einem Mercedes 500, es bekommt den Job erledigt, aber es ist nicht schön noch ist es bequem, hat die Zusammenführung eine Menge zu gewünscht sein. Ich bevorzuge das TFS-Merging-Tool, da es so aussieht, als würde der Branching-Entwickler genau dort arbeiten, so schlau es ist. Unser internes SVN schien sehr korrumpiert zu sein, deshalb haben wir es aufgegeben und sind zu TFS gegangen und haben nicht zurückgeschaut. Die Ablösung von Changesets ist wunderbar für einen agilen Entwicklungsladen, derzeit haben 270+ Ingenieure bei TFS keine Probleme oder Probleme, SVN war einfach nicht in der Lage, diese Art von Last zu bewältigen, ohne dass jemand Probleme hatte.

Ich bevorzuge CC.NET einfach wegen der Werkzeuge, die wir im Haus entwickelt haben, um die Funktionalität in der Berichterstattung und Verwaltung zu erweitern. TFS-Build ist jedoch sehr eng integriert und wir erwarten einen Wechsel, wenn wir auf SQL 2008 upgraden.