Hudson oder Teamcity für kontinuierliche Integration? [geschlossen]
100
Wir sind ein Java-Shop, der nach einem CI-Tool sucht. Sowohl Hudson als auch Teamcity scheinen frei zu sein, aber Teamcity scheint schlauer und mit mehr Unterstützung zu sein.
Ich habe mich gefragt, warum man Hudson immer noch benutzen würde und ob jemand ein Argument dafür oder dagegen liefern könnte.
Ich würde CruiseControl in die Mischung werfen - wenn Sie es noch nicht in Betracht gezogen haben. Ich kann keinen Java-Standpunkt kommentieren, da ich die .NET-Version verwendet habe, aber das gefällt mir.
AdaTheDev
3
@ire_and_curses Keine der Antworten im Beitrag gibt ein gutes Argument für eines der beiden Tools im Vergleich zum anderen
pdeva
4
-1 für Tempomat - Viel zu viele Konfigurationsdateien, die "nur so" manuell eingerichtet werden müssen.
Bevan
3
Soweit ich sehen kann, ist CruiseControl aufgrund der Existenz von kostenlosem TeamCity nicht mehr verfügbar. Ich sehe keinen Grund, CruiseControl über TeamCity zu verwenden. Und viele Gründe für das Gegenteil.
Niall Connaughton
Antworten:
113
Team City ist mit Abstand der beste CI-Server auf dem Markt. Das Killer-Feature für mich ist die enge Integration mit IDEs (IntelliJ, Eclipse und VisualStudio). Es kann Ihnen beispielsweise anzeigen, wenn eine Datei, die Sie in der IDE bearbeiten, veraltet ist, wer sie geändert hat und was sie geändert haben. Sie können von der IDE einen Commit für den CI-Server durchführen, das Comile ausführen und Tests im Build-Grid ausführen. Anschließend wird der CI-Server festgeschrieben, wenn der Build erfolgreich ist. Sie können in der CI-Webanwendung auf Berichte erstellen klicken, um die entsprechenden Dateien in der IDE zu öffnen.
Remote Run / Pre-Tested Commit sind sehr nützliche Funktionen von TeamCity. Im Allgemeinen kann TC bequemer sein, wenn Ihre Builds nicht schnell sind, da Sie in TeamCity ein kontinuierliches Feedback darüber erhalten, was in Ihrem Build passiert (wie viele Tests bestanden wurden, fehlgeschlagen sind, in welchem Stadium sich der Build befindet usw.). Auch TC-Benachrichtigungen sind komplexer. Sie können verschiedene Regeln für verschiedene Arten von Builds und für eine Vielzahl von Benachrichtigungen (E-Mail, Jabber, Windows-Taskleiste) konfigurieren.
Pavel Sher
6
@Pavel: Ich kenne TeamCity nicht so gut wie Hudson, daher werde ich den Anfang Ihres Kommentars nicht in Frage stellen. In Bezug auf die Benachrichtigungen ist die Behauptung, dass TC ausgefeilter ist, meiner nicht so bescheidenen Meinung nach reine FUD. Alle genannten Benachrichtigungskanäle sind auf Hudson verfügbar (Sie können sogar Twitter hinzufügen). Eigentlich wette ich, dass Hudson weit mehr Plugins als TC hat ( siehe wiki.hudson-ci.org/display/HUDSON/Plugins ) und ich bin sicher, dass TC mehr Einschränkungen hat als Hudson.
Pascal Thivent
3
Ich stimme den Kanälen zu (Hudson hat viele Plugins), stimme aber den Regeln nicht zu. In TeamCity können Sie Builds mit Ihren Änderungen abonnieren. Sie können festlegen, dass Sie benachrichtigt werden, wenn der Build fehlschlägt (z. B. wenn der erste Test fehlschlägt). Sie können darum bitten, beim ersten fehlgeschlagenen Build nach der Erfolgssequenz + beim ersten Erfolg nach Fehlern benachrichtigt zu werden. Diese Optionen stehen für alle Benachrichtigungskanäle zur Verfügung. Einer dieser Kanäle ist der IDE-Benachrichtiger: Wenn etwas schief geht, erhalten Sie eine Benachrichtigung direkt in Ihrer IDE. Wie ich mich erinnere, waren die Hudson-Benachrichtigungsregeln viel einfacher.
Pavel Sher
2
Pavel - Sie möchten hier kein Slinging-Match, aber standardmäßig sendet Hudson Ihnen nur eine E-Mail, wenn Sie zum fehlgeschlagenen Build beigetragen haben. Sie können auch abonnieren, um über jeden fehlgeschlagenen Build informiert zu werden, wenn Sie möchten. Es gibt auch mehr Optionen im E-Mail-Ext-Plug-In. Sie müssen es nicht gutheißen, aber wir dürfen es nicht falsch darstellen.
Jim T
4
Ein kurzer Blick auf Google zeigt Ihnen, dass es Plug-Ins zur Steuerung von Nabaztag-Kaninchen und anderen niedlichen Geräten von Team City gibt. Oder Sie können das Plug-In verwenden, auf das ich in meiner Antwort verwiesen habe . Der Vorteil einer engen IDE-Integration ist ein viel schnelleres und gezielteres Feedback zu dem Code, an dem Sie arbeiten, während Sie damit arbeiten. Sie müssen nicht auf eine Benachrichtigung warten, zum Browser wechseln, den Bericht lesen, zur IDE zurückkehren und die entsprechende Datei öffnen. Der Editorbereich ändert sich während der Arbeit, um zu zeigen, wie andere Teammitglieder den Code beeinflusst haben.
Nat
58
+1 für Hudson.
Hudson ist ein sehr aktives Projekt mit einer breiten Benutzergemeinschaft und eine Mailingliste für aktive Benutzer, die sehr einfach zu starten ist, einfach zu verwenden ist, für große, sehr große Projekte (JBoss, JAX-WS usw.) verwendet wurde und somit nachweisliche Erfolgsnachweise aufweist und sehr gute Fortgeschrittene bietet Features (zB Build Matrix, Build Clustering usw.) sind Open Source, haben viele Plugins ...
Update: Wie Sie vielleicht wissen, hat Kohsuke Kawaguchi (der Schöpfer von Hudson) Sun / Oracle verlassen und seine gestartet eigene Firma gegründet , um Hudson auf die nächste Stufe zu bringen . Mit anderen Worten, dies ist keine Bedrohung für Hudson. Wenn Sie Unterstützung suchen, können Sie eine zertifizierte Version von Hudson CI Server als Teil eines Abonnementplans erwerben (diese zertifizierte Version enthält eine hochwertige Version von Hudson mit einem vordefinierten Satz von Plugins sowie einigen kommerziellen Plugins).
Aktualisieren: Um die Größe der jeweiligen Benutzerbasis zu veranschaulichen, finden Sie hier einen Vergleich der Jobtrends für mehrere CI-Tools in Indeed (Live-Abfrage):
Vielleicht ist TeamCity so einfach zu bedienen, dass niemand speziell für die Konfiguration erforderlich ist?
Henrik
3
@ Henrik: Die Interpretation des obigen Diagramms liegt in Ihrem Ermessen. Aber ja, vielleicht ist TeamCity magisch.
Pascal Thivent
16
Wenn Sie einen Vollzeit-Build-Ingenieur einstellen, um Ihre kontinuierliche Integration durchzuführen, haben Sie jetzt zwei Probleme: 1) Ihr CI ist schwer zu bearbeiten, sodass Ihre Entwickler damit zu kämpfen haben und das Wissen im Kopf dieser einen Person sitzt. 2) Sie bezahlen jemanden für einen Job, der nicht erledigt werden muss!
Niall Connaughton
15
Wenn ich einen CI-Server auswählen würde, würde ich den auswählen, der die MINDESTEN Stellenangebote für einen dedizierten Techniker hatte, um ihn zu verwalten. Es ist ein Entwicklertool und die Entwickler sollten es selbst verwalten können. Wenn dies nicht möglich ist, benötigen Sie entweder ein anderes Tool oder andere Entwickler.
Nat
Die Job-Trend-Grafik bedeutet nicht +1 für
Hudson
17
Wir haben mit Hudson für einige Flex-Projekte begonnen und sind dann zu TeamCity migriert, als sich die .NET-Entwickler unseren CI-Bemühungen angeschlossen haben. Jetzt haben wir den TeamCity-Server wieder ausgetauscht, zurück zu Hudson. Die Hauptgründe sind: - Die lebendige Hudson-Community, besser als Unterstützung. - Die riesige Menge an Plugins für jede Art von Aufgaben. - Die Open Source. - Hudson ist kostenlos, TeamCity ist nur für 10 Projekte kostenlos.
Bearbeiten: TeamCity ist jetzt für 20 Projekte kostenlos.
Die 10 Projektbeschränkungen sind gesunken, die einzige Grenze sind jetzt 20 Build-Konfigurationen. Für kleine bis mittlere Projekte vielleicht genug.
Ashwoods
4
Welche Funktionen, die über Jenkins-Plugins verfügbar waren, fehlten aus Neugier in der TeamCity-Welt?
Behrang Saeedzadeh
14
TeamCity ist großartig, da jeder Entwickler sein eigenes Build-Profil haben und es über seine IDE einbinden kann. Dass ein Einzelner "Butt-Kickin" ist. Es gibt auch Unterstützung für GIT usw. Schauen Sie es sich ernsthaft an. Die professionelle Version ist kostenlos.
Das größte Argument dagegen Hudson ist, dass jede Veröffentlichung neue Fehler einführt.
Releases sind sehr häufig, daher müssen Sie häufig aktualisieren, damit Sie nicht ins Hintertreffen geraten. Das bedeutet, dass Sie viel Zeit für die Diagnose von Problemen und das Zurücksetzen auf frühere Hudson-Versionen aufwenden müssen. (Manchmal ist ein Rollback gar nicht möglich!)
Wir führen Continuous Deployment in unserem Shop ein (wenn Sie Code einchecken, wird er auf der Live-Site bereitgestellt!) Und das Ringen mit Hudson kostet uns zu viel.
Wir versuchen aktiv, nur wegen der Kosten für Hudsons Fehler auf TeamCity zu migrieren.
Nur weil ein Update verfügbar ist, müssen Sie kein Upgrade durchführen. Ich möchte lieber, dass sie mehr als selten veröffentlicht werden. Ich habe die Wahl, wann ich ein Upgrade durchführen möchte, und ich mache es sicherlich nicht jede Woche. Außerdem sind die Betreuer in Bezug auf die Abwärtskompatibilität sehr konservativ. Plugins benötigen im Allgemeinen nicht den neuesten Hudson, um zu funktionieren. Tatsächlich sind 130 derzeit verfügbare Plugins für Hudson-Versionen erstellt, die älter als ein Jahr sind. Wenn Sie immer noch besorgt sind, gibt es ein automatisiertes Rollback-Plugin in Arbeit ..;)
Christopher Orr
1
Nach meiner Erfahrung liegt das Problem eher bei Plugins als bei Hudson selbst, obwohl dies aus Anwendersicht keinen großen Unterschied macht. Aber nichts Sie Kräfte zu aktualisieren , es sei denn Sie einen bestimmten Fehler konfrontiert sind oder ohne eine neue Funktion nicht live. Wir folgen einfach nicht jeder Version und die Nichtverwendung der ultimativen Version ist für uns überhaupt kein Problem: "Wenn es nicht kaputt ist, beheben Sie es nicht" .
Pascal Thivent
2
Wenn der Principal Committer eine Nachricht sendet, dass ein schwerwiegender Sicherheitsfehler behoben wurde, ist dies ein Grund für eine Aktualisierung. Mein Punkt bleibt bestehen: Hudson ist einfach viel zu flockig - auch wenn KEINE zusätzlichen Plugins installiert sind.
Jdtangney
1
Ich kann sagen, dass nach anderthalb Jahren der Verwendung von Hudson / Jenkins in einem Projekt, obwohl es ein großartiges Tool ist - auch wir haben zwischen den Veröffentlichungen eine inkonsistente Qualität festgestellt - und wir nur dann ein Upgrade durchgeführt haben, wenn es unbedingt erforderlich war. Wir haben Problemumgehungen gefunden, einschließlich häufiger Sicherungen der Konfiguration. Ich freue mich darauf, TeamCity bei meinem neuesten Projekt auszuprobieren.
JaysonRaymond
4
Warum sollten Updates und Stabilität gegensätzliche Faktoren sein? Weist das nicht nur auf einen Mangel an Qualität hin?
Niall Connaughton
6
Ich mochte Teamcity wirklich, aber in der Umgebung, in der ich daran arbeite, hätte die Zeit, die benötigt würde, um eine Bestellung für Teamcity über die Verwaltungsebenen zu erhalten, wahrscheinlich die Zeit überschritten, die für die Migration von allem nach Hudson benötigt wurde.
@Pavel, wir haben mehr als 20 Benutzer und viel mehr Builds.
Sal
22
@sal es wundert mich immer wieder, wie besorgt Unternehmen über ein paar tausend Dollar für die Tools ihrer Entwicklungsteams sein können und sie lieber Hunderte von kombinierten Stunden verschwenden lassen möchten, die sie mit dem Tool nicht gehabt hätten.
Chris Marisic
5
@Chris Was ist, wenn sie mit einem kostenlosen Open Source-Tool beginnen, nur um zu sehen, wie etwas funktioniert, und 2 Jahre später zu erkennen, dass es immer noch ohne Probleme funktioniert? Würden Sie immer noch vorschlagen, ein paar tausend Dollar für ein Upgrade auf ein kommerzielles Tool auszugeben, das höchstwahrscheinlich genau das Gleiche tut?
stefanB
1
@stefan Wenn Sie ein Tool 2 Jahre lang verwendet haben und es Ihren Anforderungen entspricht, es sei denn, es gibt featureX, das Sie von einem anderen Tool benötigen, warum sollten Sie dann zu einem anderen Tool wechseln, das kostenlos oder kostenpflichtig ist?
Chris Marisic
2
Ich habe TeamCity und Jenkins (auch bekannt als der neue Hudson) bereits verwendet und eingerichtet, und obwohl ich zustimmen würde, dass TeamCity viel einfacher einzurichten ist, ist es nur für Teams mit 10 Benutzern oder weniger kostenlos. Beide Systeme sind sehr einfach einzurichten und verfügen über ein Plugin-System, das gut unterstützt wird. Die Killer-Funktion in TeamCity ist der Workflow vor dem Einchecken, in dem Sie Code testen können, bevor Sie ihn in die Quellcodeverwaltung einchecken. Das Schöne an Jenkins ist, dass er völlig kostenlos ist, selbst wenn Sie über die 10 Benutzer und Build-Agenten hinauswachsen.
Ich mag auch die Grafikansicht von Jenkins, und das fehlt mir in Teamcity. Weiter stimme ich Ihrem Kommentar zu!
Danny Gloudemans
Wenn Sie mit einem Kommentar einverstanden sind, stimmen Sie ab :)
runxc1 Bret Ferrier
1
Ich gewöhne mich gerade erst an Hudson, um zu experimentieren und zu sehen, wie es in unsere aktuelle Umgebung passt. Ich habe absolut keine Erfahrung mit Teamcity, kann mich also nicht dazu äußern, aber ich arbeite bisher gerne mit Hudson.
Ich habe Kunden empfohlen, Bambus in Betracht zu ziehen. Der Grund dafür ist, dass es (ok, nach dem Lesen der technischen Datenblätter!) Einen sehr ähnlichen Funktionsumfang wie TeamCity hat. Der Hauptvorteil ist jedoch die sehr enge Integration mit JIRA, das als Feature- / Bug-Tracking-System sehr beliebt ist. Die komplette Suite besteht aus JIRA, Greenhopper, Bamboo und Eclipse. Nicht wenige Kunden haben auch ein HP Quality Center und es gibt Plugins, die dies auch mit JIRA verbinden. Ich mag auch die Tatsache, dass JIRA, Bamboo und GreenHopper alle aus Atlassian stammen.
Nach ausgiebiger Nutzung von TeamCity sieht Jenkins sehr blank aus. Ja, Plugins ermöglichen es Ihnen, alles zu tun, sobald Sie sie installiert haben. TeamCity verfügt über ein ausgereiftes Feature-Set, mit dem Sie sofort loslegen können. Auf der Ebene der kontinuierlichen Lieferung lassen beide jedoch eine ordnungsgemäße Staging-Pipeline nicht implementiert. QuickBuild ist ein noch funktionsreicheres Produkt, das Aufmerksamkeit verdient. Es ist Payware.
bbaassssiiee
Nachdem ich Bamboo jetzt auf einer Kundenseite in Aktion gesehen habe, bin ich nicht mehr sehr daran interessiert. Es gibt einige Bereiche rund um das Erstellen von Skripten und das Übertragen von Informationen zwischen Builds, für die es schwierig ist. Das Ergebnis sind in der Regel Entwickler, die alle möglichen Dinge in den globalen Variablenbereich des CI stellen, die einfach nicht vorhanden sein sollten.
Antworten:
Team City ist mit Abstand der beste CI-Server auf dem Markt. Das Killer-Feature für mich ist die enge Integration mit IDEs (IntelliJ, Eclipse und VisualStudio). Es kann Ihnen beispielsweise anzeigen, wenn eine Datei, die Sie in der IDE bearbeiten, veraltet ist, wer sie geändert hat und was sie geändert haben. Sie können von der IDE einen Commit für den CI-Server durchführen, das Comile ausführen und Tests im Build-Grid ausführen. Anschließend wird der CI-Server festgeschrieben, wenn der Build erfolgreich ist. Sie können in der CI-Webanwendung auf Berichte erstellen klicken, um die entsprechenden Dateien in der IDE zu öffnen.
Es sind Plugins verfügbar (ich habe eines geschrieben: http://team-piazza.googlecode.com ), aber nicht viele.
quelle
+1 für Hudson.
Hudson ist ein sehr aktives Projekt mit einer breiten Benutzergemeinschaft und eine Mailingliste für aktive Benutzer, die sehr einfach zu starten ist, einfach zu verwenden ist, für große, sehr große Projekte (JBoss, JAX-WS usw.) verwendet wurde und somit nachweisliche Erfolgsnachweise aufweist und sehr gute Fortgeschrittene bietet Features (zB Build Matrix, Build Clustering usw.) sind Open Source, haben viele Plugins ...
Und wenn Support wirklich wichtig ist, können Sie kommerziellen Support von Sun erhalten . Aber FWIW, ich hatte nie ein Blockierungsproblem mit Hudson.Update: Wie Sie vielleicht wissen, hat Kohsuke Kawaguchi (der Schöpfer von Hudson) Sun / Oracle verlassen und seine gestartet eigene Firma gegründet , um Hudson auf die nächste Stufe zu bringen . Mit anderen Worten, dies ist keine Bedrohung für Hudson. Wenn Sie Unterstützung suchen, können Sie eine zertifizierte Version von Hudson CI Server als Teil eines Abonnementplans erwerben (diese zertifizierte Version enthält eine hochwertige Version von Hudson mit einem vordefinierten Satz von Plugins sowie einigen kommerziellen Plugins).
Aktualisieren: Um die Größe der jeweiligen Benutzerbasis zu veranschaulichen, finden Sie hier einen Vergleich der Jobtrends für mehrere CI-Tools in Indeed (Live-Abfrage):
Dies ist natürlich kein technischer Indikator.
quelle
Wir haben mit Hudson für einige Flex-Projekte begonnen und sind dann zu TeamCity migriert, als sich die .NET-Entwickler unseren CI-Bemühungen angeschlossen haben. Jetzt haben wir den TeamCity-Server wieder ausgetauscht, zurück zu Hudson. Die Hauptgründe sind: - Die lebendige Hudson-Community, besser als Unterstützung. - Die riesige Menge an Plugins für jede Art von Aufgaben. - Die Open Source. - Hudson ist kostenlos, TeamCity ist nur für 10 Projekte kostenlos.
Bearbeiten: TeamCity ist jetzt für 20 Projekte kostenlos.
quelle
TeamCity ist großartig, da jeder Entwickler sein eigenes Build-Profil haben und es über seine IDE einbinden kann. Dass ein Einzelner "Butt-Kickin" ist. Es gibt auch Unterstützung für GIT usw. Schauen Sie es sich ernsthaft an. Die professionelle Version ist kostenlos.
quelle
Das größte Argument dagegen Hudson ist, dass jede Veröffentlichung neue Fehler einführt.
Releases sind sehr häufig, daher müssen Sie häufig aktualisieren, damit Sie nicht ins Hintertreffen geraten. Das bedeutet, dass Sie viel Zeit für die Diagnose von Problemen und das Zurücksetzen auf frühere Hudson-Versionen aufwenden müssen. (Manchmal ist ein Rollback gar nicht möglich!)
Wir führen Continuous Deployment in unserem Shop ein (wenn Sie Code einchecken, wird er auf der Live-Site bereitgestellt!) Und das Ringen mit Hudson kostet uns zu viel.
Wir versuchen aktiv, nur wegen der Kosten für Hudsons Fehler auf TeamCity zu migrieren.
quelle
Ich mochte Teamcity wirklich, aber in der Umgebung, in der ich daran arbeite, hätte die Zeit, die benötigt würde, um eine Bestellung für Teamcity über die Verwaltungsebenen zu erhalten, wahrscheinlich die Zeit überschritten, die für die Migration von allem nach Hudson benötigt wurde.
quelle
Ich habe TeamCity und Jenkins (auch bekannt als der neue Hudson) bereits verwendet und eingerichtet, und obwohl ich zustimmen würde, dass TeamCity viel einfacher einzurichten ist, ist es nur für Teams mit 10 Benutzern oder weniger kostenlos. Beide Systeme sind sehr einfach einzurichten und verfügen über ein Plugin-System, das gut unterstützt wird. Die Killer-Funktion in TeamCity ist der Workflow vor dem Einchecken, in dem Sie Code testen können, bevor Sie ihn in die Quellcodeverwaltung einchecken. Das Schöne an Jenkins ist, dass er völlig kostenlos ist, selbst wenn Sie über die 10 Benutzer und Build-Agenten hinauswachsen.
quelle
Ich gewöhne mich gerade erst an Hudson, um zu experimentieren und zu sehen, wie es in unsere aktuelle Umgebung passt. Ich habe absolut keine Erfahrung mit Teamcity, kann mich also nicht dazu äußern, aber ich arbeite bisher gerne mit Hudson.
Es gibt viele Plugins für Hudson und die Hudson-Site gibt Ihnen viele Tipps zum Schreiben Ihrer eigenen ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).
quelle
Ich habe Kunden empfohlen, Bambus in Betracht zu ziehen. Der Grund dafür ist, dass es (ok, nach dem Lesen der technischen Datenblätter!) Einen sehr ähnlichen Funktionsumfang wie TeamCity hat. Der Hauptvorteil ist jedoch die sehr enge Integration mit JIRA, das als Feature- / Bug-Tracking-System sehr beliebt ist. Die komplette Suite besteht aus JIRA, Greenhopper, Bamboo und Eclipse. Nicht wenige Kunden haben auch ein HP Quality Center und es gibt Plugins, die dies auch mit JIRA verbinden. Ich mag auch die Tatsache, dass JIRA, Bamboo und GreenHopper alle aus Atlassian stammen.
quelle