Sep 16

Continuum vs CruiseControl

 Hace tiempo me decidí a instalar en el trabajo una de estas herramientas de integración continua, de esas que todas las noches compilan los proyectos desde cero y mandan correos a los desarrolladores y jefes sobre el éxito o fracaso de esa compilación.

En su momento evalué estas dos: CruiseControl y Continuum. Primero intenté con Continuum, porque parecía ser la más usada junto con Maven, pero me encontré con una pega en ese momento que me requería mucho trabajo para resolverla. Resulta que una vez instalado y todo a través de una interface web, le indicas a Continuum el fichero pom.xml de tu proyecto y él se encarga. La pega gorda, que me hizo desecharlo, es que en proyectos maven que tienen a su vez subproyectos debajo, Continuum obligaba a que el directorio del subproyecto se llamara igual que el artifactId de maven, cosa que en mi caso no era así. A mi me gusta poner los nombres de directorios en mayúsculas y con _ entre palabras, mientras que el artifactId coincide con el nombre del jar, y me gusta más en minúsculas y sin _. Total, que Continuum no me cogía mis proyectos maven complejos compuestos de subproyectos y no me apetecía ponerme a cambiar nombres de directorios o de jars.

La segunda pega de Continuum es que requiere que en el pom.xml esté la información para el sistema de control de versiones (CVS, Subversion, con usuario, nombre de repositorio y proyecto…. y password). Estupendo si es uno solo, pero si hay varios desarrolladores, ¿de quién ponemos ahí la información?. Por supuesto, habría que crear un usuario "anonimo" con acceso de sólo lectura al sistema de control de versiones. Cosa compleja si el servidor es de CVS y además corporativo. Nada menos que una petición al departamente de informática y un "agujero" de seguridad dejando un acceso público a nuestros "super secretos fuentes" (es un decir).

Así que me puse a probar con CruiseControl. Este fue bastante mejor. No tiene casi ningún tipo de configuración a través de interface web, por lo que todo se configura a mano. Tú te haces el checkout, le dices a CruiseControl en un fichero xml dónde están los fuentes, cada cuánto tiene que compilarlos, a quién tiene que enviar correos y listo. La interface web es además mucho más sencilla, un listado de proyectos con un botón de "build" al lado y un enlace para ver los resultados del compilado y poder bajarse los jar.

Así estuvimos funcionando unos años, pero CruiseControl fue presentando sus pegas. El fichero xml de configuración con los proyectos empezó a crecer y crecer, hasta hacerse una pesadilla cualquier modificación (había que tocar en muchos proyectos). Y encima, el botón de "build" le funciona a unos sí y a otros no, con unos navegadores sí y con otros no, y sin una regla fija. A unos les funciona con Internet explores, a otros con firefox, a otros con ninguno. Y otra pega más, a veces, si el código de los test automáticos de JUnit se queda colgado por el motivo que sea, deja colgadas todas las tareas siguientes de compilación de otros proyectos en CruiseControl. No queda más remedio que "matarlo" y volverlo a arrancar.

El otro día decimos bajar y probar una nueva versión de Continuum. Esta vez sí funcionó el importar los pom.xml, puesto que ya admite nombres de directorios y artifactId distintos. La configuración a través de web de todo el sistema es sencilla, aunque si no hace lo que tú quieres, no se puede hacer. Sigue habiendo cosas ocultas en ficheros de configuración ocultos, como la configuración del servidor de correo para que Continuum pueda enviar correos. Y sigue habiendo cosas que no sé si me gustan, como la necesidad del usuario anónimo en CVS y que en el pom.xml deben estar todos los nombres de desarrolladores y correos que intervengan en el proyecto (cosa lógica por un lado, pero que no deja de ser un rollo ponerlo y tenerlo actualizado). En este sentido, CruiseControl usaba el nombre de usuario del commit de cvs para enviarle el correo, o bien hacer un mapeo de ese nombre con una dirección de correo si no coincide.

Pero bueno, ahí tenemos un Continuum instalado y funcionando, hasta ahora bien, y después de un par de meses de prueba quizás (seguro) que nos cargamos el CruiseControl.

Entradas relacionadas:

4 Responses to “Continuum vs CruiseControl”

  1. Blaxter Says:

    En mi curro usamos bitten, mayormente porque es muy personalizable (es python, en 30min cree “soporte” para proyectos ruby, aún tengo pendiente desde febrero mandarlo al proyecto :P), aunque otro que me gustó mucho (y para proyectos java se adapta muy bien) es hudson. Muy potente.

    Al final la elección fue para bitten porque (1) se integra muy bien con trac (herramienta principal que usamos), (2) es mucho más lenguaje-agnóstico que el resto (pero vamos en cualquiera si puedes ejecutar un build.sh o similar…), y (3) es mucho más simple modificarlo y adaptarlo que hudson que es mucho más complejo (aunque tiene un sistema de plugins que parecía muy pensado, por lo que supongo que en vez de 30min me costaría 3h, pero ya es java y hay que compilar y tal).

    Por cierto, una cosa imprescindible (por experiencia lo digo) es activar notificaciones (yo prefiero vía mail, ¡pero hudson tenía incluso bots jabber/irc!) cuando el build falla, sino de poco sirve la integración continua.

  2. Blaxter Says:

    Por cierto, para ahorrar búsqueda a google:
    Bitten: http://bitten.edgewall.org/Hudson: https://hudson.dev.java.net/
    :). Continuum no estaba mal, pero era muy limitado y simple, muy simple (está muy atado a maven), CruiseControl a mi parecer muy complejo y sobrecargado, y sino recuerdo mal la configuración era solo vía xml y con mil historias que luego no usarías ni la mitad (recuerdo un app conectándose con jmx o algo así, WTF?, ¡yo solo quiero ejecutar un comando!, ¡un cron!), aparte de fea la interfaz xD y ni me quiero imaginar intentar modificarlo.

  3. Chuidiang Says:

    Gracias, echaré un ojo a esos que comentas, hudson y bitten.

    En nuestro caso es java+maven y sólo java+maven, siempre hacemos sólo aplicaciones de escritorio java, así que Continuum nos viene bien, salvo por las pegas que comento y que tú también comentas.

    Se bueno.

  4. Diario de Programación » Blog Archive » Hudson Says:

    […] comentario de Blaxter me ha llevado a probar las herramientas que él indica para integración continua, en […]

Leave a Reply