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

Question

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 de Java, pero la configuración para esos es bastante básica en este momento (sin embargo, podemos hacer más cosas más adelante). Los proyectos de C++, haga lo siguiente:

• Construye todo con opciones de si se debe volver a configurar, hacer una construcción limpia, o utilizar una copia nueva
• Opcionalmente construye y ejecuta todas las pruebas
• Opcionalmente se ejecuta todas las pruebas usando Valgrind de Memcheck
• ejecuta Cppcheck
• Genera documentación doxygen
• publica informes: las pruebas unitarias, valgrind, cppcheck, las advertencias del compilador, SLOC, tareas abiertas, y la cobertura de código (usando gcov, GCO vr, y el plugin de Cobertura)
• Despliega código de noche o bajo demanda a un entorno de prueba y un repositorio de paquetes

Todo es configurable para automática construye y opcional para la demanda construye. 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.

Empezamos a utilizar Hudson (en ese momento) porque eso es lo que los chicos de Java estaban usando 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 visto 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 estamos usando Hudson? ¿Por qué?

EDIT: Alguien me preguntó por qué no he encontrado a Hudson/Jenkins como 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 surjan nuevos requisitos.

Answer 1

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

En general, diría que buildbot es la herramienta de construcción automática más "general". Sin embargo, Jenkins podría ser el mejor relacionado con la ejecución de pruebas, especialmente para analizar y presentar resultados de forma agradable (resultados, detalles, gráficos ... algunos clics de distancia), cosas que buildbot no hace "out-of-the-box". De hecho, estoy pensando en usar ambos para tener páginas de resultados de prueba más atractivas .. :-)

También como regla general, no debería ser difícil crear una nueva configuración de herramienta: si la especificación de qué hacer (configuraciones , compilaciones, pruebas) es demasiado difícil cambiar de una herramienta a otra, es una señal (mala) de que no se han movido suficientes guiones de configuración a las fuentes. Buildbot (o Jenkins) solo debe llamar a comandos simples.Si es simple ejecutar 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, se ejecutará para corregir las fallas del nuevo código y se perderá. su valor sin regresión, solo mi 0.02 € :-)

Espero que ayude.

Answer 2

La 'integración de resultados' también está en jenkins/hudson, y usted puede capturar productos de construcción de manera relativamente fácil 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 todos integrados. Para nuestro código C++, los complementos son un poco insuficientes, pero aún puede obtener la mayor parte.

ejecutamos buildbot desde pre 0.7, y ahora estamos ejecutando 0.8 y solo ahora estamos viendo una razón real para cambiar, ya que buildbot 0.8 se olvidó de los esclavos de Windows por un período prolongado y el soporte fue bastante pobre.

Answer 3

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

• TeamCity por JetBrains
• bambú por Atlassian
• Ir por ThoughtWorks
• Cruise Control
• OpenMake Meister

Aspectos específicos de lo que estás haciendo no es tan importante, de hecho, siempre y cuando los agentes (alias nodos) en los que los estás haciendo sean compatibles con esas tareas.

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

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

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