¿Qué marco de integración continua utiliza y por qué? [cerrado]

Existen bastantes marcos de integración continua (CI) diferentes y me pregunto cuál es el más popular. ¿Qué marcos ha utilizado en las empresas donde trabaja?

¿Hay alguna razón por la cual un marco de trabajo de CI es más popular que otro?

Parece que la integración continua se usa más en los mundos Java y .net que ruby ​​o python. ¿Por qué es esto?

Hudson o Jenkins (este último es un tenedor del primero). Motivo: es simple (fácil de instalar y usar) y tiene una gran flexibilidad. Los complementos agregan casi todas las funcionalidades que se me ocurren.

Hace algunos años usé el control de daños . También era fácil de usar, pero no tenía los complementos. Pero el autor decidió que renunciaría a la solución simple y comenzó a desarrollar una nueva versión, que consistía en diferentes servidores que se comunicaban entre sí (¿qué demonios?). Eso no funcionó bien y el proyecto fue abandonado. Estuve buscando algún tiempo, pero ni el control de crucero (demasiado complicado) ni el continuo realmente me atraparon. Hasta Hudson, eso funcionó desde el primer momento para mí.

Yo uso TeamCity en el trabajo y en casa. Tiene un gran soporte para una variedad de corredores de compilación y es extensible a través de complementos.

No tratar con montones de XML para la configuración es una gran ventaja en mis libros y la versión gratuita es suficiente para las necesidades de mi hogar.

Un problema que encontré con TeamCity tiene que ver con tratar de llevarlo a la versión automática de los ensamblados .NET. Tuve que configurar una solución relativamente complicada, pero una vez que estuvo en su lugar, funcionó a las mil maravillas.

Personalmente, solo he usado CruiseControl y CruiseControl.Net. La razón de esto tiene que ver con la economía. Son razonablemente estables y una vez que los configura, realmente hay poco que hacer para mantenerlo. La comunidad de usuarios suele ser muy útil y puede ampliarse a sus necesidades.

Dicho esto, hay un par de ofertas comerciales disponibles que conozco (una de JetBrains, la otra de Atlassian) que ofrecen una mejor experiencia de configuración y soporte comercial. He tenido la intención de probar estas ofertas, pero realmente aún no he tenido la oportunidad.

Las herramientas de CI tienen un papel más importante que jugar con los lenguajes compilados que los lenguajes interpretados, pero eso no quiere decir que la herramienta de CI se desperdicie en los idiomas interpretados. Cuando tiene varios proyectos que dependen unos de otros, y desea asegurarse de que un cambio no rompa accidentalmente sus dependencias, las herramientas de CI son invaluables.

Hay tres clases generales de problemas que las herramientas de CI pueden ayudarlo a detectar:

1. Errores de compilación: si la firma de una clase cambia de una manera que rompe las dependencias, es mejor saberlo antes de las horas de espera de un entregable.
2. Errores lógicos: si el comportamiento de una clase cambia de una manera que rompe las dependencias, es mejor saberlo pronto. Esto debe verificarse mediante algún tipo de prueba automatizada, más comúnmente pruebas unitarias.
3. Pruebas de aceptación: si tiene un conjunto automatizado de pruebas para ejecutar en el producto terminado, es mejor ejecutarlas con frecuencia.

Los lenguajes interpretados no se compilan, por lo que no hay errores de compilación que atrapar. Sin embargo, los otros dos problemas son lo suficientemente comunes como para que las herramientas de CI sean útiles para proyectos en Ruby / Python / Perl / etc.

La palabra clave tanto en los errores lógicos como en los puntos de prueba de aceptación es la prueba "automatizada". Si no tiene un conjunto de pruebas que una máquina pueda ejecutar, entonces realmente está perdiendo los mayores beneficios de las herramientas de CI. Las suites automatizadas se pueden construir con el tiempo, para que pueda comenzar con poco.

Editar

Vea este buen cuadro para ver comparaciones de características de una gran cantidad de herramientas de CI (muchas de las cuales no conocía):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Team Foundation Server

CI sólido, estrecha integración con Visual Studio y Git como control de versión . He visto servidores CI más flexibles, como Hudson, pero la estrecha integración de TFS con otros productos hace que la experiencia sea tan fluida que tiene sentido para mi equipo.

Yo uso tanto CruiseControl.NET y Hudson . Algunas de mis compilaciones están en una de ellas y otras están en la otra.

¿Por qué? ¡Porque yo no soy el ingeniero de construcción y él, que es el ingeniero de construcción, los configuró de esta manera!

No tengo ningún problema con la forma en que se configuran mis compilaciones o quejas sobre cualquiera de los productos. ¡Te informo de la manera en que están las cosas aquí, de manera casual y espero que aprecies esta perspectiva!

ACTUALIZACIÓN: desde que publiqué la respuesta, Hudson se bifurcó y se convirtió en Jenkins . La recomendación anterior se aplica a Jenkins.

Pulso . Básicamente funciona, lo que para un ingeniero de construcción ocupado es un gran problema. También tienen un soporte técnico realmente excelente. La razón principal por la que me encanta es porque tenemos más de 250 proyectos y los maneja sin problemas; No puedo decir lo mismo de Hudson.

Nuestro equipo trabaja principalmente en Python, C ++ y Java. Utilizamos Buildbot para CI. Inicialmente comenzamos con él porque se integra con Trac y porque parecía simple y directo. Creo que es el marco de elección de CI en el mundo de Python.

Hudson A veces es un poco defectuoso, y algunos de los complementos más interesantes en realidad no funcionan, pero con un poco de agarre es bastante útil.

Probablemente usaría Pulse en su lugar, pero si necesita construir en múltiples plataformas es> $ 5k, que es un poco demasiado.

CruiseControl.NET para una integración continua. Funciona bastante bien, aunque con la gran cantidad de proyectos de compilación que hemos configurado en CruiseControl, la aplicación de bandeja de escritorio CCTray no responde, incluso con largos intervalos de actualización.

NAnt es para los scripts de compilación que se ejecutan en los proyectos CruiseControl. Para scripts de compilación más complejos, hemos ampliado NAnt con tareas personalizadas de C # NAnt, lo cual es muy agradable: escribir código en C # es mucho más agradable que crear scripts de NAnt.

Somos una tienda de Microsoft y, en teoría, nos mudaremos a Team Build 2010 de Microsoft una vez que migremos nuestro entorno de Team Foundation Server a 2010.

Tenga en cuenta que debería poder compilar su aplicación desde la línea de comandos, independientemente de si tiene un motor CI funcionando o no.

Esto significa que todo lo que hace el motor CI es sistematizar sus invocaciones de compilación, y usted puede elegir el motor que mejor se adapte a sus necesidades particulares.

Personalmente, me gusta Hudson principalmente porque "se siente" bien, pero sé que si todo falla puedo cambiar a otro sin demasiado esfuerzo. Si es así, probablemente investigaría primero el realizado por Atlassian, ya que me gusta la "sensación" de los otros programas que hacen.

Tenga en cuenta que la capacidad de intercambio implica que no importa en qué idioma estén escritos. Creo que Java fue elegido para muchos motores porque las muchas plataformas compatibles, combinadas con los muchos bloques de construcción fácilmente disponibles. Necesita un servidor web: tome uno. Necesita muchos hilos concurrentes, solo úselos. Necesita extensibilidad - colóquelo en un frasco.

Antes de escuchar el término "integración continua" (esto fue en 2002 o 2003) escribí un script de compilación nocturno que se conectaba a cvs, tomé una copia limpia del proyecto principal y los cinco subproyectos más pequeños, construí todos los los frascos a través de Ant luego construyeron y volvieron a desplegar un archivo WAR a través de un segundo script de hormiga que usaba las tareas de Tomcat Ant.

Se ejecutó a través de cron a las 7 p.m. y envió un correo electrónico con un montón de archivos de salida adjuntos. Lo usamos durante los 7 meses completos del proyecto y se mantuvo en uso durante los siguientes 20 meses de mantenimiento y mejoras.

Funcionó bien, pero aún prefiere hudson sobre los scripts de bash, cron y ant.