buildbot vs hudson / jenkins para la integración continua de C++

Actualmente estoy usando jenkins/hudson para la integración continua de un gran proyecto en su mayoría C++. Tenemos proyectos separados para el tronco y cada rama. Además, hay algunos proyectos relacionados para el código Java, pero la configuración para ellos es bastante básica en este momento (aunque podemos hacer más tarde). Los proyectos C++ hacen lo siguiente:

  • Construye todo con opciones para reconfigurar, hacer una compilación limpia o usar un nuevo checkout
  • Opcionalmente construye y ejecuta todo pruebas
  • Opcionalmente ejecuta todas las pruebas usando memcheck de Valgrind
  • Ejecuta cppcheck
  • Genera documentación doxygen
  • Publica informes: pruebas unitarias, valgrind, cppcheck, advertencias del compilador, SLOC, tareas abiertas y cobertura de código (usando gcov, gcovr y el complemento cobertura)
  • Despliega código todas las noches o bajo demanda en un entorno de prueba y un repositorio de paquetes

Todo es configurable para compilaciones automáticas y opcional para compilaciones bajo demanda. Debajo, hay un script bash que controla gran parte de esto, que depende más de nuestro sistema de compilación, que utiliza automake y autoconf junto con scripts bash personalizados.

Empezamos a usar Hudson (en ese momento) porque eso es lo que los chicos de Java estaban usando y solo queríamos nightly builds. Desde entonces, hemos añadido mucho más y seguimos añadiendo más. En cierto modo Hudson es genial, pero ciertamente no es ideal.

He mirado otras soluciones y la única que se parece a ella podría ser un reemplazo es buildbot. ¿Buildbot sería mejor para esta situación? ¿Vale la pena la inversión ya que ya estamos usando Hudson? ¿Por qué?

EDIT: Alguien preguntó por qué no he encontrado que Hudson/Jenkins sea ideal. La respuesta corta es que todo se puede mejorar. Simplemente me pregunto si Jenkins es la mejor solución actual para mi caso de uso o si hay algo mejor (buildbot?) que sería más fácil de mantener en el largo plazo, incluso como nuevos requisitos sube.

Author: deuberger, 2011-04-13
Source

3 answers

Ambos son proyectos de código abierto, pero no necesita cambiar el código buildbot para "extenderlo", en realidad es bastante fácil importar sus propios paquetes en su configuración en la que puede subclasificar la mayoría de las características con sus propias adiciones. Ejemplos: su propia compilación o código de prueba, algunos análisis de salidas / errores que se darán a los siguientes pasos, su propia formación de correos electrónicos de alerta, etc. hay muchas posibilidades.

Generalmente diría que buildbot es el más " general propósito " automatic construye herramientas. Jenkins, sin embargo, podría ser el mejor relacionado con la ejecución de pruebas, especialmente para analizar y presentar resultados de manera agradable (resultados, detalles, gráficos.. algunos clics de distancia), cosas que buildbot no hace "fuera de la caja". En realidad estoy pensando en usar ambos para tener páginas de resultados de pruebas más sexys.. :-)

También como regla general no debería ser difícil crear la configuración de una nueva herramienta: si la especificación de qué hacer (configuraciones, compilaciones, pruebas) es demasiado difícil de cambiar de una herramienta a otra, es una señal (mala) de que no se mueven suficientes scripts de configuración a las fuentes. Buildbot (o Jenkins) solo debería llamar a comandos simples. Si es simple ejecutar pruebas, entonces los desarrolladores lo harán también y esto mejorará la tasa de éxito, mientras que si solo el sistema de integración continua ejecuta las pruebas, se ejecutará después de él para corregir los fallos del nuevo código, y perderá su valor de no regresión, solo mi 0.02€: -)

Espero que ayude.

 41
Author: Christophe Muller,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-05 18:09:58

Hay muchas otras soluciones por ahí, además de Jenkins / Hudson/BuildBot:

  • TeamCity de Jetbrains
  • Bambú por Atlassian
  • Go by Thoughtworks
  • Control de crucero
  • OpenMake Meister

Los detalles sobre lo que está haciendo no son tan importantes, de hecho, siempre y cuando los agentes (también conocidos como nodos) que los está haciendo soporten esas tareas.

La belleza de un servidor CI es notar cuando la compilación cambia para activar una nueva compilación (y prueba), publicar los artefactos y publicar los resultados de la prueba.

Al comparar herramientas de CI como las que mencionamos, considere características como la usabilidad de su interfaz, lo fácil que es la ramificación (y características que podría ofrecer como la fusión automática), notificaciones (como XMPP/jabber) o un radiador de información (como conectar un monitor para mostrar siempre el estado). El soporte de productos es otra cosa a considerar: el soporte de Jenkins solo es tan bueno como quién responde a las preguntas de la comunidad en el es hora de que tengas preguntas.

Mi favorito personal es el bambú, pero viene con una tarifa de licencia.

 6
Author: macetw,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-03 17:23:41

La 'integración de resultados' también está en jenkins/hudson, y puede capturar relativamente fácilmente productos de compilación sin tener que 'copiarlos en otro lugar'.

Para nuestra instancia, los informes de cobertura y las métricas de prueba unitaria y javadoc para el código java están integrados. Para nuestro código C++, los complementos son un poco deficientes, pero aún puede obtener la mayor parte.

Ejecutamos buildbot desde antes de 0.7, y ahora estamos ejecutando 0.8 y solo ahora vemos alguna razón real para cambiar, como buildbot 0.8 se olvidó de los esclavos de Windows durante un período prolongado de tiempo y el soporte era bastante pobre.

 5
Author: Terry,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-06-27 19:05:16