buildbot vs hudson / jenkins für die kontinuierliche Integration von C ++

Ich verwende derzeit Jenkins / Hudson für die kontinuierliche Integration eines großen, meist C ++ - Projekts. Wir haben separate Projekte für Trunk und jede Niederlassung. Es gibt auch einige verwandte Projekte für den Java-Code, aber die Einrichtung für diese Projekte ist derzeit recht einfach (wir können jedoch später mehr tun). Die C ++ - Projekte führen Folgendes aus:

• Erstellt alles mit Optionen, ob neu konfiguriert, sauber erstellt oder eine neue Kasse verwendet werden soll
• Erstellt optional alle Tests und führt sie aus
• Führt optional alle Tests mit Valgrinds Memcheck aus
• Führt cppcheck aus
• Erzeugt Sauerstoffdokumentation
• Veröffentlicht Berichte: Unit-Tests, Valgrind, Cppcheck, Compiler-Warnungen, SLOC, offene Aufgaben und Codeabdeckung (mit gcov, gcovr und dem Cobertura-Plugin)
• Stellt Code jede Nacht oder bei Bedarf in einer Testumgebung und einem Paket-Repository bereit

Alles ist für automatische Builds konfigurierbar und für On-Demand-Builds optional. Darunter befindet sich ein Bash-Skript, das einen Großteil davon steuert. Dies hängt weiter von unserem Build-System ab, das Automake und Autoconf zusammen mit benutzerdefinierten Bash-Skripten verwendet.

Wir haben (zu der Zeit) angefangen, Hudson zu verwenden, weil die Java-Leute das verwendeten und wir wollten nur nächtliche Builds. Seitdem haben wir viel mehr hinzugefügt und fügen weitere hinzu. In gewisser Hinsicht ist Hudson großartig, aber sicherlich nicht ideal.

Ich habe mir andere Lösungen angesehen und die einzige, die aussieht, als könnte sie ein Ersatz sein, ist Buildbot. Wäre Buildbot für diese Situation besser? Lohnt sich die Investition, da wir bereits Hudson einsetzen? Warum?

EDIT : Jemand fragte, warum ich Hudson / Jenkins nicht als ideal empfunden habe. Die kurze Antwort lautet, dass alles verbessert werden kann. Ich frage mich nur, ob Jenkins die derzeit beste Lösung für meinen Anwendungsfall ist oder ob es etwas Besseres gibt (Buildbot?), Das auf lange Sicht einfacher zu warten wäre, selbst wenn neue Anforderungen auftauchen.

Beide sind Open-Source-Projekte, aber Sie müssen den Buildbot-Code nicht ändern, um ihn zu "erweitern". Es ist eigentlich recht einfach, Ihre eigenen Pakete in ihrer Konfiguration zu importieren, in der Sie die meisten Funktionen mit Ihren eigenen Ergänzungen unterordnen können. Beispiele: Ihre eigene Kompilierung oder Ihr eigener Testcode, einige Analysen der Ausgaben / Fehler, die für die nächsten Schritte erforderlich sind, Ihre eigene Formatierung von Alarm-E-Mails usw. Es gibt viele Möglichkeiten.

Im Allgemeinen würde ich sagen, dass Buildbot das am häufigsten verwendete automatische Build-Tool für allgemeine Zwecke ist. Jenkins ist jedoch möglicherweise am besten für das Ausführen von Tests geeignet, insbesondere zum Parsen und Präsentieren von Ergebnissen auf nette Weise (Ergebnisse, Details, Diagramme ... einige Klicks entfernt), Dinge, die Buildbot nicht "out-of-the-box" macht. Ich denke tatsächlich daran, beide zu verwenden, um sexy Testergebnisseiten zu haben .. :-)

Als Faustregel sollte es auch nicht schwierig sein, die Konfiguration eines neuen Tools zu erstellen: Wenn die Spezifikation der zu erledigenden Aufgaben (Konfigurationen, Builds, Tests) zu schwierig ist, um von einem Tool zum anderen zu wechseln, ist dies ein (schlechtes) Zeichen dass nicht genügend Konfigurationsskripte in die Quellen verschoben werden. Buildbot (oder Jenkins) sollten nur einfache Befehle aufrufen. Wenn es einfach ist, Tests auszuführen, werden dies auch Entwickler tun, was die Erfolgsrate verbessert. Wenn jedoch nur das kontinuierliche Integrationssystem die Tests ausführt, werden Sie danach ausgeführt, um die neuen Codefehler zu beheben, und verlieren sein Nicht-Regressionswert, nur meine 0,02 € :-)

Hoffe es wird helfen.

Die 'Ergebnisintegration' ist auch in Jenkins / Hudson, und Sie können Build-Produkte relativ einfach erfassen, ohne sie 'woanders kopieren' zu müssen.

In unserem Fall sind die Abdeckungsberichte und Unit-Test-Metriken sowie Javadoc für den Java-Code integriert. Für unseren C ++ - Code fehlen die Plugins etwas, aber Sie können immer noch das meiste davon bekommen.

Wir haben Buildbot seit vor 0.7 ausgeführt und führen jetzt 0.8 aus und sehen erst jetzt einen wirklichen Grund für einen Wechsel, da Buildbot 0.8 Windows-Slaves für einen längeren Zeitraum vergessen hat und die Unterstützung ziemlich schlecht war.

Neben Jenkins / Hudson / BuildBot gibt es noch viele andere Lösungen:

• TeamCity von Jetbrains
• Bambus von Atlassian
• Gehen Sie an Thoughtworks vorbei
• Tempomat
• OpenMake Meister

Die Einzelheiten zu dem, was Sie tun, sind in der Tat nicht so wichtig, solange die Agenten (auch als Knoten bezeichnet), für die Sie sie ausführen, diese Aufgaben unterstützen.

Das Schöne an einem CI-Server ist, dass sich der Build ändert, um einen neuen Build (und Test) auszulösen, die Artefakte zu veröffentlichen und Testergebnisse zu veröffentlichen.

Berücksichtigen Sie beim Vergleich von CI-Tools wie den oben genannten Funktionen wie die Benutzerfreundlichkeit der Benutzeroberfläche, die einfache Verzweigung (und Funktionen wie das automatische Zusammenführen), Benachrichtigungen (wie XMPP / Jabber) oder einen Informationsstrahler (wie das Einhängen) einen Monitor hochfahren, um immer den Status anzuzeigen). Produktunterstützung ist eine weitere zu berücksichtigende Sache - Jenkins Unterstützung ist nur so gut wie die, die zum Zeitpunkt Ihrer Fragen auf Community-Fragen antwortet.

Mein persönlicher Favorit ist Bambus, aber es kommt mit einer Lizenzgebühr.

Ich bin ein langjähriger Jenkins-Benutzer, der gerade Buildbot evaluiert, und möchte ein paar Artikel für Leute anbieten, die Buildbot für Multi-Modul-Lösungen verwenden möchten:

*) Buildbot verfügt nicht über ein sofort einsatzbereites Dateikonzept artifactsfür jeden Build. Es ist nicht in der Benutzeroberfläche und es ist nicht in einem der eingebauten "Schritte" -Module, soweit ich sehen kann:

http://docs.buildbot.net/current/manual/configuration/buildsteps.html

... und ich sehe kein Plugin von Drittanbietern:

https://github.com/buildbot/buildbot/wiki/PluginList#steps

Buildbot sammelt zwar die gesamte Konsolenausgabe eines bestimmten Builds, aber kritisch gesehen können Sie keine damit verbundenen Dateien sammeln .

*) Da Artefakte nicht unterstützt werden, ist es nicht einfach, "Collector" -Projekte zu erstellen, die mehrere Module in einem einzigen Installationsprogramm zusammenfassen. Jenkins hat eine großartige Funktion, mit der Sie einen Build mit Builds aus anderen Modulen parametrisieren können (der Parametertyp ist a run).

*) Das Herstellen von Abhängigkeiten zwischen Modulen ist in Buildbot schwieriger. Angenommen, Sie haben eine Bibliothek, von der drei Binärdateien abhängen, und Sie möchten, dass diese Binärdateien bei jeder Änderung der Bibliothek neu erstellt werden. Jenkins hat triggersin die Benutzeroberfläche eingebaut. Wenn Sie Trigger in Buildbot ausführen möchten, müssen Sie diese mithilfe von Skripten ausführen. Dies schedulers.Dependentführt zu einer starken Überlastung der SchedulersBenutzeroberfläche.

*) Wenn Sie in Buildbot arbeiten, scheint es, dass fast die gesamte Konfiguration master.cfgim Code erfolgt. Das ist großartig und frustrierend.

*) Buildbot zwingt Sie, workerzusätzlich zu einem masterServer einen zu erstellen . Dies ist ärgerlich für Anfänger und Systeme, für die ein einziger Build-Server ausreicht.

Mein Eindruck nach zwei Tagen Buildbot-Evaluierung ist, dass wir bei Jenkins bleiben werden, hauptsächlich aufgrund dessen artifacts. Buildbot ist ein Tool, das wir nur verwenden würden, wenn wir umfangreichere Anpassungsanforderungen hätten und die Zeit dafür hätten.

Zum Thema Buildbot und Artefakte - ich habe nicht genügend Benutzerwerte, um einen Kommentar abzugeben - können Sie Artefakte aus der Buildbot 2.x-Serie mit integrierten Aktionen zum Hochladen von Dateien / Verzeichnissen ganz einfach abrufen. Sie möchten jedoch selten nur Dateien verschieben. In der Regel führen Sie einen ausgelösten Buildstep durch, der die Bereitstellung direkt vom Worker aus ausführt, um die besten Ergebnisse zu erzielen. zB Push-to-Cloud-Speicher, Container, Dritte (Steam-Uploads) usw.

Auf diese Weise können Sie Metriken für die Uploads abrufen und diese unter bestimmten Bedingungen besser steuern (oder sogar Artefakte auf verschiedenen Arbeitsmaschinen mischen und abgleichen).