Was ist der Unterschied zwischen Hudson und CruiseControl für Java-Projekte?

Ich denke der Titel bringt es auf den Punkt. Ich möchte nur wissen, warum das eine oder andere besser für Continuous-Integration-Builds von Java-Projekten von Svn ist.

Ich stimme dieser Antwort zu, wollte aber ein paar Punkte hinzufügen.

Zusamenfassend, Hudson (aktualisieren: Jenkins) ist jetzt wahrscheinlich die bessere Wahl. In erster Linie, weil das Erstellen und Konfigurieren von Jobs (“Projekte” im CC-Vokabular) gerecht ist so viel schneller über die Web-Benutzeroberfläche von Hudson, im Vergleich zum Bearbeiten der XML-Konfigurationsdatei von CruiseControl (die wir früher in der Versionskontrolle aufbewahrt haben, nur um sie besser im Auge zu behalten). Letzteres ist nicht besonders schwierig – es ist einfach langsamer und mühsamer.

CruiseControl war großartig, aber wie in Dan Dyers treffend benanntem Blogbeitrag erwähnt, Warum verwenden Sie Hudson immer noch nicht?, es leidet darunter, der Erste zu sein. (Ähm, wie Großbritannien, wenn Sie so wollen, später in der industriellen Revolution, als andere anfingen, es mit neueren Technologien zu überholen.)

Wir haben CruiseControl stark genutzt und sind nach und nach auf Hudson umgestiegen, um es schließlich ausschließlich zu verwenden. Und sogar mehr stark: Dabei haben wir begonnen, den CI-Server für viele andere Dinge als zuvor zu verwenden, weil das Einrichten und Verwalten von Hudson-Jobs so praktisch ist. (Wir haben jetzt mehr als 40 Jobs in Hudson: die üblichen Build- und Test-Jobs für stabile und Entwicklungszweige; Jobs im Zusammenhang mit der Veröffentlichung (Erstellen von Installern usw.); Jobs, die einige (experimentelle) Metriken gegen die Codebasis ausführen; solche, die (langsam ) UI- oder Integrationstests für eine bestimmte Datenbankversion usw.)

Aufgrund dieser Erfahrung würde ich argumentieren, dass Hudson eine ziemlich sichere Wahl ist, selbst wenn Sie viele Builds haben, einschließlich komplizierter, da Sie es wie CC verwenden können irgendetwas, Grundsätzlich. Konfigurieren Sie einfach Ihren Job so, dass er beliebige Ant- oder Maven-Ziele, Unix-Shell-Skripte oder Windows-.bat-Skripte in der gewünschten Reihenfolge ausführt.

Was die Sachen von Drittanbietern betrifft (hier erwähnt von Jeffrey Fredrick) – das ist ein guter Punkt, aber ich habe den Eindruck, dass Hudson schnell aufholt und dass es bereits eine sehr große Anzahl davon gibt Plugins verfügbar dafür.

Für mich sind die zwei Dinge, die ich an CruiseControl vermisse, die ich nennen kann:

1. Seine Warn-E-Mails über kaputte Builds waren informativer als die von Hudson. In den meisten Fällen war die eigentliche Ursache aus der schön formatierten HTML-Mail von CC selbst ersichtlich, während ich bei Hudson normalerweise dem Link zur Hudson-Webbenutzeroberfläche folgen und ein wenig herumklicken muss, um die Details zu erhalten.
2. Das CruiseControl-Dashboard eignet sich out of the box besser als “Informationsstrahler” (wird auf einem öffentlichen Monitor angezeigt oder an eine Wand projiziert, damit Sie immer schnell den Status aller Projekte sehen können). Bei Hudsons Titelseite brauchten wir einige Greasemonkey-Tricks, um Jobreihen schön grün/rot zu bekommen.

Kleiner Haftungsausschluss: Ich habe das CC-Projekt im letzten Jahr oder so nicht genau verfolgt. (Aber von a schneller Blickes hat sich nicht dramatisch verändert.)

Notiz (2011-02-03): Hudson war umbenannt/forked wie Jenkins (vom Hudson-Schöpfer Kohsuke Kawaguchi und andere). Es sieht so aus, als würde Oracle – das den Namen Hudson kontrolliert – „Hudson” auch herum, aber meine persönliche Empfehlung ist, mitzumachen Jenkinsegal was Oracle sagt.

Als langjähriger CruiseControl-Committer und jemand, der Hudson noch nie benutzt hat Ich bin ziemlich voreingenommen, aber meine Meinung dazu ist:

Hudson ist viel einfacher zum Laufen zu bringen (zum großen Teil über eine nette Weboberfläche) und hat eine sehr aktive Plugin-Entwicklungsgemeinschaft.

CruiseControl wird von vielen unterstützt Zeug von Drittanbietern und hat den Vorteil, einige nette Tricks mit der XML-Konfiguration wie Plugin-Vorkonfiguration und include.projects auszuführen, mit denen Sie die Konfigurationsinformationen mit dem Projekt versionieren können.

Wenn Sie nur ein paar Builds haben, denke ich, dass Hudson der klare Gewinner ist. Wenn Sie viel haben wollen – und XML nichts dagegen haben – dann werden die XML-Konfigurationstricks von CruiseControl meiner Meinung nach zu einer echten Stärke.

Mein letztes Projekt, wir haben mit CruiseControl angefangen. Was gerockt hat. Dann zogen wir zu Hudson, das noch mehr rockte. Was mir an Hudson gefallen hat:

• Die vor- und nachgelagerten Projekte. Ein Commit für Ihren Datenzugriffscode löst also schließlich auch einen Build der Präsentationsschicht aus.

• Verwenden Sie ganz einfach ein vorhandenes Projekt als Ausgangspunkt für ein neues. Wenn Sie also daran gewöhnt sind, Entwicklungszweige zu erstellen, ist es ein Kinderspiel, dafür zu sorgen, dass diese kontinuierlich integriert werden.

Ein Unterschied besteht darin, dass Hudson das Produkt eines einzigen genialen Intellekts ist – Kohsuke Kawaguchi. Aus diesem Grund ist es konsistent, kohärent und absolut solide. Der Nachteil könnte eine gewisse Einschränkung der Fortschrittsrate sein. Kohsuke ist jedoch unglaublich produktiv, also würde ich mir darüber keine allzu großen Sorgen machen. Und es ist erweiterbar, also wenn es etwas gibt, für das Kohsuke keine Zeit hat (oder nicht will), können Sie es wahrscheinlich selbst tun.

Ich habe mir sowohl Cruise Control als auch Hudson angesehen, aber Hudson gewählt, da es viel einfacher einzurichten und zu konfigurieren war. Hudson scheint heutzutage sehr weit verbreitet zu sein, mit regelmäßigen Veröffentlichungen und viel Erweiterbarkeit durch Plugins. Ich würde es sehr empfehlen.

Hudson ist meiner Meinung nach die benutzerfreundlichere Alternative. Es kann komplett über das Webinterface eingerichtet und gewartet werden (abgesehen natürlich von der Erstinstallation der Webapp).

Das kann man über CruiseControl nur sagen, wenn man den eingebauten XML-Dateieditor mitzählt.

Trotzdem würde ich, nachdem ich beide verwendet habe, immer noch einen bevorzugen, anstatt keinen automatisierten Build zu haben.

Ich habe die Geschwindigkeitsregelung ausprobiert … Es ist gut … Aber die Dokumente sind fragmentiert. Dashboard ist verwirrend. Die Widget-Erstellung ist auch verwirrend. Nie versucht Hudson. Werde es am Wochenende versuchen.