Wie wählt man zwischen Hudson und Jenkins? [geschlossen]

Ich habe ungefähr eine Stunde gebraucht, um herauszufinden, dass Hudson erst vor kurzem (Januar / 2011) verzweigt ist.
Ich habe keine Ahnung, wie schnell sich die einzelnen Zweige jetzt ändern, aber was noch wichtiger ist, in welche Richtung sich die einzelnen Zweige bewegen und welche Schlüssel sind Punkte, damit man eine Wahl treffen kann, mit welchen man gehen soll?

Hat jemand Links zu Produkt-Roadmap und Funktionsunterschieden?

Verwenden Sie Jenkins .

Jenkins ist die jüngste Abzweigung der Kernentwickler von Hudson. Um zu verstehen, warum, müssen Sie die Geschichte des Projekts kennen. Es war ursprünglich Open Source und wurde von Sun unterstützt. Wie vieles, was Sun tat, war es ziemlich offen, aber es gab ein bisschen gütige Vernachlässigung. Die Quelle, die Tracker, die Website usw. wurden von Sun auf ihrer relativ geschlossenen java.net-Plattform gehostet.

Dann kaufte Oracle Sun. Aus verschiedenen Gründen hat sich Oracle nicht gescheut, das zu nutzen, was es als sein Vermögen wahrnimmt. Dazu gehört eine gewisse Kontrolle über die Logistikplattform von Hudson und insbesondere die Kontrolle über den Namen Hudson. Viele Benutzer und Mitwirkende waren damit nicht zufrieden und beschlossen zu gehen.

Es kommt also darauf an, was Hudson gegen Jenkins bietet. Sowohl Oracle's Hudson als auch Jenkins haben den Code. Hudson hat die Unternehmensunterstützung von Oracle und Sonatype sowie die Marke. Jenkins hat die meisten Kernentwickler, die Community und (bisher) viel mehr tatsächliche Arbeit.

Lesen Sie, dass ich oben verknüpft schreiben, dann lesen Sie den Rest dieses in chronologischer Reihenfolge . Für das Gleichgewicht können Sie die Hudson / Oracle- Version lesen . Mir ist ziemlich klar, wer defensiv spielt und wer echte Absichten für das Projekt hat.

Verwenden Sie Jenkins, wie Chmullig schrieb . Einige zusätzliche Punkte:

• In der Tat war es wohl Oracle, der das Gabeln gemacht hat ! Und auch technisch ist das passiert .

• Es ist jedoch interessant zu sehen, was aus "Hudson" herauskommt. Während das Zeug "Winston fasst den Zustand und die rosige Zukunft des Hudson-Projekts zusammen", das sie auf der (neuen) Hudson-Website veröffentlicht haben, mir ursprünglich seltsam vorkam, war dies vielleicht eine gezielte Übernahme, und die Sonatype-Leute haben tatsächlich einige große Ideen ihr Ärmel. Diese Analyse , die eine bewusste Strategie von Oracle / Sonatype vorschlägt, um Kohsuke und die Crew zu verdrängen, um einen "unternehmerischeren" Hudson zu schaffen, ist eine sehr interessante Lektüre!

• Auf jeden Fall zeigt dieser kurze Vergleich zwei Wochen nach der Trennung - obwohl nicht gerade wissenschaftlich -, dass Jenkins bei beiden Projekten weitaus aktiver ist.

... und ein paar Hintergrundinformationen:

Der Schöpfer von Hudson, Kohsuke Kawaguchi , startete das Projekt in seiner Freizeit, auch wenn er für Sun Microsystems arbeitete und später von ihnen bezahlt wurde, um es weiterzuentwickeln. Wie @erickson bei einer anderen SO-Frage feststellte ,

[Hudson / Jenkins] ist das Produkt eines einzigen genialen Intellekts - Kohsuke Kawaguchi. Aus diesem Grund ist es konsistent, kohärent und absolut solide.

Nach der Übernahme durch Oracle blieb Kohsuke nicht lange ( ^{wegen fehlender Monitore ...?; -]} ) und machte sich an die Arbeit für CloudBees . Was Ende 2010 als Konflikt um Tools zwischen der Entwickler-Community und Oracle begann und mit dem Umbenennen / Fork / Split endete, ist in den bereitgestellten Links chmullig gut dokumentiert. Für mich spricht dieses ganze Rätsel vielleicht mehr als alles andere für die völlige Unfähigkeit oder den Unwillen von Oracle, ein Open-Source-Projekt so zu sponsern, dass alle Beteiligten (Oracle, Entwickler, Benutzer) zufrieden sind. Es liegt nicht in ihrer DNA oder so, wie wir auch in anderen Fällen gesehen haben.

Angesichts all dessen würde ich Kohsuke und anderen Kernentwicklern in dieser Angelegenheit persönlich folgen und mich Jenkins anschließen.

Nur meine Meinung zu dieser Angelegenheit, drei Monate später:

Jenkins hat den vom ursprünglichen Hudson eingeschlagenen Weg mit häufigen Veröffentlichungen, einschließlich vieler kleinerer Updates, fortgesetzt.

Oracle scheint die Arbeit am zukünftigen Weg für Hudson weitgehend an das Sonatype-Team delegiert zu haben, das einige bedeutende Änderungen vorgenommen hat, insbesondere in Bezug auf Maven. Sie haben es gemeinsam in die Eclipse-Stiftung verlegt.

Ich würde vorschlagen, wenn Sie den Klang mögen von:

• weniger häufige Releases, aber solche, die stärker auf Abwärtskompatibilität getestet wurden (eher ein Release-Zyklus im "Enterprise-Stil")
• Ein Produkt, das sich hauptsächlich auf eine starke Maven- und / oder Nexus-Integration konzentriert (dh Sie haben kein Interesse an Gradle und Artifactory usw.).
• Professionelle Support-Angebote von Sonatype oder Oracle von Cloudbees usw.
• Es macht Ihnen nichts aus, eine kleinere Community von Plugin-Entwicklern usw. zu haben.

, dann würde ich Hudson vorschlagen.

Umgekehrt, wenn Sie es vorziehen:

• häufigere Updates, auch wenn sie etwas häufiger angepasst werden müssen und hinsichtlich der Kompatibilität möglicherweise etwas riskanter sind (eher ein "neuester und größter" Release-Zyklus)
• Ein System mit aktiverer Community-Unterstützung für z. B. andere Build-Systeme / Artefakt-Repositorys
• Unterstützungsangebote des ursprünglichen Erstellers et al. und / oder Sie haben kein Interesse an professioneller Unterstützung (z. B. sind Sie glücklich, solange Sie in den "neuesten und besten" der nächsten Woche eine Lösung finden können)
• ein klassisches Hexengebräu im OSS-Stil eines Entwicklungsökosystems

dann würde ich Jenkins vorschlagen. (und wie ein Kommentator bemerkte, hat Jenkins jetzt auch "LTS" -Versionen, die in einem "stabileren" Zweig gepflegt werden)

Der konservative Kurs wäre, sich jetzt für Hudson zu entscheiden und nach Jenkins zu migrieren, wenn die erforderlichen Funktionen nicht verfügbar sind. Der dynamische Kurs wäre, sich jetzt für Jenkins zu entscheiden und nach Hudson zu migrieren, wenn das Verfolgen von Updates zu zeitaufwändig wird, um dies zu rechtfertigen.

Vorne .. Ich bin ein Hudson-Committer und Autor des Hudson-Buches, aber ich war nicht an der gesamten Aufteilung der Projekte beteiligt.

Auf jeden Fall ist hier mein Rat:

Schauen Sie sich beide an und finden Sie heraus, was Ihren Anforderungen besser entspricht.

Hudson wird die Migration zu einem Eclipse-Projekt der obersten Ebene im Laufe dieses Jahres abschließen und hat eine ganze Reihe von Vollzeitentwicklern, Qualitätssicherern und anderen an dem Projekt arbeiten lassen. Es ist immer noch stark und hat viele Benutzer. Da es der Standard-CI-Server bei Eclipse ist, wird es weiterhin den Anforderungen vieler Java-Entwickler gerecht. Wenn Sie sich die Roadmap und die Pläne für die Zukunft ansehen, können Sie sehen, dass nach der Integration von Maven 3 mit der Version 2.1.0 eine ganze Reihe weiterer interessanter Funktionen vor Ihnen liegen.

http://www.eclipse.org/hudson

Jenkins auf der anderen Seite hat viele ursprüngliche Hudson-Benutzer überzeugt und verfügt über eine große Benutzergemeinschaft mit mehreren Technologien sowie eine ganze Reihe von Entwicklern, die daran arbeiten.

In dieser Phase sind beide CI-Server großartige Tools, und je nach Ihren technologischen Anforderungen ist die Integration in den einen oder anderen möglicherweise besser. Beide Produkte sind als Open Source erhältlich und Sie können kommerziellen Support von verschiedenen Unternehmen für beide erhalten.

Auf jeden Fall ... wenn Sie noch keinen CI-Server verwenden ... beginnen Sie jetzt mit einem der beiden und Sie werden enorme Vorteile sehen.

Update Jan 2013: Nach einem langen Prozess der IP-Bereinigung und weiteren Verbesserungen ist Hudson 3.0 als erste von der Eclipse Foundation genehmigte Version jetzt verfügbar.

Jenkins ist der neue Hudson. Es ist wirklich eher eine Umbenennung, keine Abzweigung, da die gesamte Entwicklergemeinschaft nach Jenkins gezogen ist. (Oracle sitzt in einer Ecke und hält seinen alten Ball "Hudson", aber jetzt ist es nur ein seelenloses Projekt.)

Vgl. Ethereal -> WireShark

Ich muss zwei Punkte hinzufügen. Erstens dreht sich bei Hudson / Jenkins alles um die Plugins. Plugin-Entwickler sind zu Jenkins gewechselt, und wir, die Benutzer, sollten dies auch tun. Zweitens bin ich persönlich kein großer Fan von Oracle-Produkten. Tatsächlich vermeide ich sie wie die Pest. Für das Geld, das für Lizenzierung und Hardware für eine Oracle-Lösung ausgegeben wird, können Sie das doppelte technische Personal einstellen und haben jeden Freitag noch etwas übrig, um Bier zu kaufen :)

Für diejenigen, die eine Versöhnung als potenzielle Zukunft für Hudson und Jenkins erwähnt haben, mit der Tatsache, dass Jenkins SPI beitreten wird , ist es zu diesem Zeitpunkt unwahrscheinlich , dass sie sich versöhnen werden.

Auf der Jenkins-Website http://jenkins-ci.org wird dies im Folgenden zusammengefasst.

Kurz gesagt, Jenkins CI ist der führende Open-Source-Server für die kontinuierliche Integration. Es wurde mit Java erstellt und bietet über 300 Plugins, mit denen praktisch jedes Projekt erstellt und getestet werden kann.

Oracle besitzt jetzt die Marke Hudson, hat sie jedoch unter der Eclipse EPL lizenziert . Jenkins ist auf der MIT-Lizenz . Sowohl Hudson als auch Jenkins sind Open Source. Basierend auf der Kombination Ihrer Mitarbeiter und Ihrer persönlichen Präferenz für Open Source ist die Entscheidung meiner Meinung nach unkompliziert.

Hoffe das war hilfreich.