continuous integration - Hudson o Teamcity para la integración continua?

hudson vs jenkins

Question

Somos una tienda de Java que busca una herramienta de CI para usar. Tanto Hudson como Teamcity parecen ser libres, pero Teamcity parece más astuto y con más apoyo.

Me preguntaba por qué uno seguiría usando Hudson y si alguien podría proporcionar algún argumento a favor o en contra de cualquiera de los dos.

Answer 1

+1 por Hudson.

Hudson es un proyecto muy activo, tiene una amplia comunidad de usuarios y una lista de correo de usuarios activos, es realmente fácil de usar, es fácil de usar, se ha utilizado en proyectos enormes, muy grandes (JBoss, JAX-WS, etc.) y, por lo tanto, cuenta con registros comprobados de éxito, ofertas muy buenas avanzadas características (por ejemplo, matriz de construcción, clústeres de compilación, etc.), es de código abierto, tiene muchos complementos ...

Y si el soporte es realmente algo importante, puede obtener soporte comercial de Sun. Pero FWIW, nunca tuve ningún problema de bloqueo con Hudson.

Actualización: Como sabrá, Kohsuke Kawaguchi (el creador de Hudson) dejó Sun / Oracle y comenzó su propia empresa para llevar a Hudson a la siguiente etapa . En otras palabras, esto no es una amenaza para Hudson. Y si busca soporte, puede obtener una versión certificada de Hudson CI Server como parte de un plan de suscripción (esta versión certificada incluye una versión de alta calidad de Hudson con un conjunto predefinido de complementos más algunos comerciales).

Actualización: para ilustrar el tamaño de su respectiva base de usuarios, aquí hay una comparación de tendencias de trabajo para varias herramientas de CI en Indeed (consulta en vivo):

Esto, por supuesto, no es un indicador técnico.

Answer 2

Comenzamos con Hudson para un par de proyectos de Flex, luego migramos a TeamCity, cuando los desarrolladores de .NET se unieron a nuestros esfuerzos de CI. Ahora hemos reemplazado el servidor de TeamCity nuevamente, de vuelta a Hudson. Las principales razones son: - La vibrante comunidad Hudson, mejor que el soporte. - La gran cantidad de complementos para todo tipo de tareas. - La fuente abierta. - Hudson es gratis, TeamCity solo es gratis para 10 proyectos.

editar: TeamCity ahora es gratis para 20 proyectos.

Answer 3

El mayor argumento contra Hudson es que cada lanzamiento presenta nuevos errores.

Las versiones son muy frecuentes, por lo que debe actualizar con frecuencia para no quedarse atrás. Eso significa que debe dedicar mucho tiempo a diagnosticar problemas y volver a versiones anteriores de Hudson. (¡A veces una reversión ni siquiera es posible!)

Estamos introduciendo el Despliegue continuo en nuestra tienda (¡cuando ingresas el código, se implementa en el sitio en vivo!) Y tener que luchar con Hudson nos está costando demasiado.

Estamos buscando activamente migrar a TeamCity solo por el costo de los errores de Hudson.

Answer 4

Estoy empezando a acostumbrarme a Hudson listo para experimentar y ver cómo encajará en nuestro entorno actual. No tengo absolutamente ninguna experiencia con Teamcity, así que no puedo comentar sobre eso, pero estoy disfrutando de trabajar con Hudson hasta el momento.

Hay muchos complementos para Hudson más el sitio Hudson le brinda muchos consejos para escribir el suyo ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

Answer 5

He estado recomendando a clientes que consideren a Bamboo. La razón es que (¡bueno, por leer las hojas de especificaciones!) Tiene una característica muy similar a la de TeamCity. Sin embargo, el principal beneficio es una integración muy estrecha con JIRA, que es bastante popular como un sistema de seguimiento de fallas / características. La suite completa es JIRA, Greenhopper, Bamboo y Eclipse. Muchos clientes también tienen HP Quality Center y hay complementos que también se unen a JIRA. También me gusta el hecho de que JIRA, Bamboo y GreenHopper provengan de Atlassian.

Answer 6

He usado y configurado TeamCity y Jenkins (también conocido como el nuevo Hudson) antes, y aunque estoy de acuerdo en que TeamCity es mucho más astuto de configurar, solo es gratuito para equipos de 10 usuarios o menos. Ambos sistemas son muy fáciles de configurar y tienen un sistema de complementos que está bien soportado. La característica principal de TeamCity es el flujo de trabajo previo a la verificación en el que puede probar el código antes de verificarlo en el control de código fuente y lo bueno de Jenkins es que es completamente gratuito incluso si crece más allá de los 10 usuarios y agentes de compilación.

Answer 7

Realmente me gustó Teamcity, pero en el entorno en el que estoy trabajando, el tiempo que tomaría obtener una Orden de compra para Teamcity a través de las capas de administración probablemente habría excedido el tiempo que se tardó en migrar todo a Hudson.

Answer 8

Team City es de lejos el mejor servidor de CI que existe. Su característica principal para mí es la estrecha integración con IDE (IntelliJ, Eclipse y VisualStudio). Puede mostrarle, por ejemplo, cuando un archivo que está editando en el IDE queda desactualizado, quién lo cambió y qué cambió. Puede comprometer desde el IDE al servidor de CI, ejecutar el comile y las pruebas en la cuadrícula de compilación, y luego el servidor de CI se comprometerá si la construcción es exitosa. Puede hacer clic en informes de compilación en la aplicación web de CI y abrirá los archivos apropiados en el IDE.

Hay complementos disponibles (escribí uno: http://team-piazza.googlecode.com ), pero no muchos.

Answer 9

TeamCity es genial porque permite que cada desarrollador tenga su propio perfil de compilación y que lo conecte desde su IDE. Que un solitario es ''pateador''. También hay soporte para GIT, etc. Mírelo seriamente. La versión profesional es gratis.