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

Actualmente estoy usando jenkins / hudson para la integración continua de un gran proyecto principalmente en C ++. Tenemos proyectos separados para troncal y cada sucursal. 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 más adelante). Los proyectos de C ++ hacen lo siguiente:

• Compila todo con opciones para reconfigurar, hacer una compilación limpia o usar una caja nueva
• Opcionalmente, crea y ejecuta todas las pruebas.
• Opcionalmente ejecuta todas las pruebas usando Memcheck de Valgrind
• Ejecuta cppcheck
• Genera documentación de doxygen
• Publica informes: pruebas unitarias, valgrind, cppcheck, advertencias del compilador, SLOC, tareas abiertas y cobertura de código (usando gcov, gcovr y el complemento de cobertura)
• Implementa 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 además depende de nuestro sistema de compilación, que usa automake y autoconf junto con scripts bash personalizados.

Comenzamos a usar Hudson (en ese momento) porque eso es lo que usaban los chicos de Java y solo queríamos compilaciones nocturnas. Desde entonces, hemos agregado mucho más y seguimos agregando más. En cierto modo, Hudson es genial, pero ciertamente no es ideal.

He analizado otras soluciones y la única que parece que 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é?

EDITAR : 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 a largo plazo incluso cuando surgen nuevos requisitos.

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

En general, diría que buildbot es la herramienta de compilación automática más "de propósito general". Sin embargo, Jenkins podría ser el mejor relacionado con la ejecución de pruebas, especialmente para analizar y presentar resultados de formas agradables (resultados, detalles, gráficos ... algunos clics de distancia), cosas que buildbot no hace "fuera de la caja". De hecho, estoy pensando en usar ambos para tener páginas de resultados de prueba más sexys .. :-)

Además, 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 para cambiar de una herramienta a otra, es una (mala) señal 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 las pruebas, los desarrolladores también lo harán y esto mejorará la tasa de éxito, mientras que si solo el sistema de integración continua ejecuta las pruebas, lo ejecutará para corregir las fallas del nuevo código y perderá su valor de no regresión, solo mi 0.02 € :-)

Espero que te ayude.

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

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

ejecutamos buildbot desde la versión anterior a 0.7, y ahora estamos ejecutando 0.8 y solo ahora vemos alguna razón real para cambiar, ya que buildbot 0.8 se olvidó de los esclavos de Windows durante un período de tiempo prolongado y el soporte fue bastante pobre.

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

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

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

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

Cuando compare herramientas de CI como las que mencionamos, considere características como la usabilidad de su interfaz, qué tan fácil es la ramificación (y las características que podría ofrecer, como la fusión automática), las notificaciones (como XMPP / jabber) o un radiador de información (como enganchar un monitor para mostrar siempre el estado). El soporte del producto es otra cosa a considerar: el soporte de Jenkins es tan bueno como quién esté respondiendo a las preguntas de la comunidad en el momento en que usted tenga preguntas.

Mi favorito personal es Bamboo, pero viene con una tarifa de licencia.

Soy un usuario de Jenkins desde hace mucho tiempo y estoy evaluando Buildbot y me gustaría ofrecer algunos elementos para las personas que están considerando usar Buildbot para soluciones de varios módulos:

*) Buildbot no tiene ningún concepto de archivo listo para usar artifactsrelacionado con cada compilación. No está en la interfaz de usuario y no está en ninguno de los módulos de "pasos" incorporados por lo que puedo ver:

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

... y no veo ningún complemento de terceros:

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

Buildbot recopila toda la salida de la consola de una compilación determinada, pero, fundamentalmente, no puede recopilar archivos relacionados con ella.

*) Dado que los artefactos no son compatibles, no es fácil crear proyectos de "coleccionista" que traigan varios módulos en, digamos, un solo instalador. Jenkins tiene una gran característica que le permite parametrizar una compilación con compilaciones de otros módulos (el tipo de parámetro es a run).

*) Establecer dependencias entre módulos es más complicado en Buildbot. Supongamos que tiene una biblioteca de la que dependen tres binarios y desea que esos binarios se reconstruyan cada vez que cambie la biblioteca. Jenkins se ha triggersintegrado en la interfaz de usuario. Si desea hacer desencadenadores en Buildbot, debe escribirlos usando schedulers.Dependent, y causa mucha congestión de elementos en la Schedulersinterfaz de usuario.

*) Cuando trabajas en Buildbot, parece que casi toda la configuración se realiza en master.cfg en código. Esto es asombroso y frustrante.

*) Buildbot te obliga a crear un workercomplemento a un masterservidor. Esto es molesto para principiantes y sistemas para los que un solo servidor de compilación es suficiente.

Mi impresión después de dos días de evaluación de Buildbot es que nos quedaremos con Jenkins, principalmente debido a que tiene artifacts. Buildbot es una herramienta que solo usaríamos si tuviéramos necesidades de personalización más extensas y el tiempo para hacerlo.

Sobre el tema de buildbot y artefactos, no tengo suficiente puntaje de usuario para hacer un comentario, puede obtener artefactos de la serie buildbot 2.x con bastante facilidad con las acciones de carga de archivos / directorios integradas. Sin embargo, rara vez desea mover archivos. Por lo general, realiza un paso de compilación desencadenado que se implementa directamente desde el trabajador para obtener mejores resultados. por ejemplo, enviar a almacenamiento en la nube, contenedores, terceros (cargas de Steam), etc.

De esta manera, puede obtener métricas sobre las cargas y controlarlas mejor condicionalmente (o incluso mezclar y combinar artefactos en las máquinas de trabajo).