Buildbot vs Hudson/Jenkins für C++ kontinuierliche Integration




continuous-integration (2)

Ich benutze derzeit jenkins / hudson für die kontinuierliche Integration eines großen meist C ++ - Projekts. Wir haben separate Projekte für Stamm und jede Branche. Es gibt auch einige verwandte Projekte für den Java-Code, aber das Setup für diese ist im Moment ziemlich einfach (wir können später mehr tun). Die C ++ - Projekte machen folgendes:

  • Erstellt alles mit Optionen für die Neukonfiguration, einen sauberen Build oder einen neuen Checkout
  • Erstellt und führt optional alle Tests aus
  • Führt optional alle Tests mit Valminds memcheck aus
  • Führt cppcheck aus
  • Erzeugt doxygen Dokumentation
  • Publiziert Berichte: Komponententests, Valgrind, cppcheck, Compilerwarnungen, SLOC, offene Aufgaben und Codeabdeckung (mit gcov, gcovr und dem cobertura-Plugin)
  • Implementiert Code nächtlich oder bei Bedarf in eine Testumgebung und ein Paket-Repository

Alles ist konfigurierbar für automatische Builds und optional für On-Demand-Builds. Darunter befindet sich ein Bash-Skript, das vieles davon steuert, was wiederum von unserem Build-System abhängt, das automake und autoconf zusammen mit benutzerdefinierten Bash-Skripten verwendet.

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

Ich habe mir andere Lösungen angeschaut und der einzige, der aussieht, als könnte es ein Ersatz sein, ist Buildbot. Wäre der Bau für diese Situation besser? Lohnt sich die Investition, weil wir Hudson bereits verwenden? Warum?

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


Beide sind Open-Source-Projekte, aber Sie müssen den Buildbot-Code nicht ändern, um ihn zu "erweitern". Es ist wirklich ziemlich einfach, eigene Pakete in seiner Konfiguration zu importieren, in denen Sie die meisten Features mit Ihren eigenen Zusätzen untergliedern können. Beispiele: eigene Compilier- oder Test-Codes, ein Parsing von Ausgängen / Fehlern für die nächsten Schritte, eigene Formatierung von Alarm-E-Mails etc. Es gibt viele Möglichkeiten.

Generell würde ich sagen, dass buildbot die "allzweck" automatische Build-Tools ist. Jenkins könnte jedoch am besten mit laufenden Tests zu tun haben, insbesondere zum Parsen und Darstellen von Ergebnissen auf nette Weise (Ergebnisse, Details, Diagramme ... einige Klicks entfernt), Dinge, die buildbot nicht "out-of-the-box" macht. Ich denke eigentlich daran, beide zu verwenden, um sexierere Testergebnisseiten zu haben .. :-)

Auch als Faustregel sollte es nicht schwierig sein, die Konfiguration eines neuen Tools zu erstellen: Wenn die Spezifikation dessen, was zu tun ist (Configs, Builds, Tests), zu schwierig ist, um von einem Tool zu einem anderen zu wechseln, ist es ein (schlechtes) Zeichen dass nicht genügend Konfigurationsskripte in die Quellen verschoben werden. Buildbot (oder Jenkins) sollte nur einfache Befehle aufrufen. Wenn es einfach ist, Tests auszuführen, dann werden auch Entwickler dies tun und dies wird die Erfolgsrate verbessern, während, wenn nur das kontinuierliche Integrationssystem die Tests ausführt, Sie danach laufen werden, um die neuen Code-Fehler zu beheben, und verlieren werden sein Nicht-Regressionswert, nur meine 0.02 € :-)

Ich hoffe, es wird dir helfen.


Die 'Ergebnisintegration' ist auch in jenkins / hudson, und Sie können Build-Produkte relativ einfach erfassen, ohne sie an anderer Stelle kopieren zu müssen.

Für unsere Instanz sind alle Coverage-Berichte und Unit-Test-Metriken und 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 0.7 laufen lassen und laufen jetzt 0.8 und sehen jetzt nur noch einen wirklichen Grund um zu wechseln, da buildbot 0.8 Windows Slaves für einen längeren Zeitraum vergaß und die Unterstützung ziemlich schlecht war.







buildbot