Somos una tienda de Java en busca de una herramienta de CI a utilizar. Tanto Hudson y Teamcity parecen ser gratis, pero TeamCity parece más pulido y con más apoyo.Hudson o Teamcity para una integración continua?
Me preguntaba por qué uno todavía usaría Hudson y si alguien podría proporcionar algún argumento a favor o en contra de cualquiera de los dos?
+1 para Hudson.
Hudson es un proyecto muy activo, tiene una amplia comunidad de usuarios y un usuarios activos lista de correo, es muy fácil para empezar, es fácil de usar, se ha utilizado en grandes, muy grandes, proyectos (JBoss , JAX-WS, etc.) y por lo tanto tiene registros comprobados de éxito, ofrece funciones avanzadas muy agradables (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 una cosa importante, puede obtener
commercial support from Sun. Pero FWIW, nunca tuve ningún problema de bloqueo con Hudson.
Actualización: Como ya sabrán, Kohsuke Kawaguchi (el creador de Hudson) ha dejado de Sun/Oracle y comenzó su own companypara tomar Hudson a la siguiente etapa. En otras palabras, esto no es una amenaza para Hudson. Y si usted está buscando ayuda, se puede obtener una certified version of Hudson CI Server como parte de un plan de suscripción (esta versión certificada lía un comunicado de alta calidad de Hudson con un conjunto predefinido de los plugins más algo de uno comercial).
Actualización: Para ilustrar el tamaño de su respectiva base de usuarios, que aquí hay una comparación de las tendencias de empleo para varias herramientas de CI en Indeed (consulta en directo):
Esto es, por supuesto, no un indicador técnico.
¿Quizás TeamCity es tan fácil de usar, como para no requerir que alguien específicamente empleado lo configure? – Henrik
@Henrik: la interpretación del gráfico anterior es a su criterio. Pero sí, quizás TeamCity es mágico. –
Si contrata un ingeniero de compilación a tiempo completo para ejecutar su integración continua, ahora tiene dos problemas: 1) Su CI es difícil de trabajar, por lo que sus desarrolladores tendrán problemas y el conocimiento se quedará en la cabeza de esta persona , 2) le está pagando a alguien para que haga un trabajo que no debería necesitar hacer! –
Team City es, de lejos, el mejor servidor de CI que existe. Su función única para mí es la estrecha integración con entornos de desarrollo (IntelliJ, Eclipse y VisualStudio). Se puede mostrar, por ejemplo, cuando un archivo que está editando en el IDE se vuelve fuera de fecha, que lo cambió y lo cambiaron. Puede comprometerse desde el IDE al servidor IC, ejecute la comilla y pruebas en la parrilla de acumulación, y luego el servidor CI se comprometerá si la acumulación se realiza correctamente. Puede hacer clic en informes de compilación en la aplicación web de CI y abrirá los archivos apropiados en el IDE.
Hay plugins disponibles (escribí uno: http://team-piazza.googlecode.com), pero no muchos.
La ejecución remota/confirmación probada previamente son características muy útiles de TeamCity. En general, TC puede ser más conveniente si sus compilaciones no son rápidas, porque en TeamCity obtiene retroalimentación continua sobre lo que ocurre en su compilación (cuántas pruebas pasaron, fallaron, en qué etapa se encuentra la compilación, etc.). También las notificaciones de TC son más sofisticadas. Puede configurar diferentes reglas para diferentes tipos de compilaciones y para una amplia gama de notificadores (correo electrónico, Jabber, bandeja de Windows). –
@Pavel: no conozco a TeamCity ni a Hudson, así que no voy a cuestionar el comienzo de su comentario. Pero, con respecto a las notificaciones, afirmar que TC es más sofisticado es puro FUD en mi opinión no tan humilde. Todos los canales de notificación mencionados están disponibles en Hudson (incluso puede agregar twitter). En realidad, apuesto a que Hudson tiene muchos más complementos que TC (consulte http://wiki.hudson-ci.org/display/HUDSON/Plugins) y estoy seguro de que TC tiene más limitaciones que Hudson. –
Acepto los canales (Hudson tiene muchos complementos), pero no estoy de acuerdo con las reglas. En TeamCity puede suscribirse a construcciones con sus cambios, puede optar por recibir notificaciones cuando la construcción comienza a fallar (por ejemplo, cuando la primera prueba comienza a fallar). Puede solicitar que se le notifique en la primera compilación fallada después de la secuencia de éxito + en el primer éxito después de las fallas. Y estas opciones están disponibles para todos los canales de notificación. Uno de esos canales es el notificador IDE: cuando algo va mal recibirás una notificación directamente en tu IDE. Como recuerdo, las reglas de notificación de Hudson fueron mucho más simples. –
Me gustó mucho Teamcity pero en el entorno en el que estoy trabajando, el tiempo que tardaría en obtener una orden de compra para Teamcity a través de las capas de gestión probablemente habría excedido el tiempo que se tardó en migrar todo a Hudson.
TeamCity professional es gratuito. –
@Pavel, tenemos más de 20 usuarios y muchas compilaciones más que eso. – sal
@sal siempre me sorprende cómo las empresas pueden estar tan preocupadas por un par de miles de dólares para las herramientas de sus equipos de desarrollo y preferirían que desperdicien cientos de horas combinadas que no habrían tenido con la herramienta. –
TeamCity es excelente porque permite que cada desarrollador tenga su propio perfil de compilación y 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.
GIT también es compatible con Jenkins/Hudson – CJBrew
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 da muchos consejos para escribir el suyo (http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson).
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.
Las 10 restricciones del proyecto han disminuido, el único límite ahora son 20 configuraciones de compilación. Para proyectos pequeños o medianos, tal vez sea suficiente. – ashwoods
Por curiosidad, ¿qué características que estaban disponibles a través de los complementos de Jenkins faltaban en el mundo de TeamCity? – Behrang
El mayor argumento contra Hudson es que cada versión presenta nuevos errores.
Las versiones son muy frecuentes, por lo que debe actualizarse 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 presentando el Despliegue continuo en nuestra tienda (cuando ingresa el código, se implementa en el sitio en vivo) y tener que luchar con Hudson nos está costando demasiado .
Estamos buscando activamente la migración a TeamCity solo por el costo de los errores de Hudson.
El hecho de que haya una actualización disponible no significa que deba actualizar. Preferiría que soltaran más-que menos-a menudo. Es mi elección cuándo actualizar, y ciertamente no lo hago todas las semanas. Además, los mantenedores son muy conservadores con respecto a la compatibilidad con versiones anteriores. Los complementos generalmente no requieren el último Hudson para funcionar. De hecho, 130 complementos disponibles ahora están diseñados contra versiones de Hudson que tienen más de un año de antigüedad. Si aún le preocupa, hay un complemento de reversión automatizado en curso ...;) –
Desde mi experiencia, el problema es más con los complementos que Hudson, aunque esto no hace una gran diferencia desde un punto de usuario de ver. Pero, * nada * te obliga a actualizar a menos que estés enfrentando un error en particular o no puedas vivir sin una nueva característica. Simplemente no seguimos cada versión y no usar la última versión no es un problema para nosotros: * "Si no está roto, no lo arregles" *. –
Cuando el comitente principal envía un mensaje que dice que se ha solucionado una falla importante de seguridad, esa es una razón para actualizar. Mi punto sigue en pie: Hudson es demasiado simple, incluso sin instalar ningún complemento adicional. – jdtangney
He estado recomendando a clientes que consideren 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.
Después de un uso extenso de TeamCity, Jenkins se ve muy desnudo. Sí, los complementos le permiten hacer cualquier cosa, una vez que los instala. TeamCity tiene un conjunto de características maduras que te permite salir de la caja. Sin embargo, en el nivel de entrega continua, ambos dejan una tubería de puesta en escena adecuada sin implementar. QuickBuild es un producto aún más rico en características que merece atención, es payware. – bbaassssiiee
Al haber visto a Bamboo en acción en el sitio de un cliente, ya no estoy muy interesado en él. Hay algunas áreas alrededor de scripting y transferencia de información entre compilaciones que se esfuerza por hacer. Los resultados tienden a ser que los desarrolladores pongan todo tipo de cosas en el área de variables globales de CI que simplemente no deberían estar allí. – drekka
He utilizado 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 gratis 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.
También me gusta la vista gráfica de Jenkins, y eso es lo que me falta en Teamcity. ¡Además, estoy de acuerdo con tu comentario! – Gynnad
Si está de acuerdo con un comentario, vuélvalo a votar :) –
Puede que esté interesado en las respuestas aquí: http://stackoverflow.com/questions/1200721/language-agnostic-automated-build-and-test-server-for-multiple-projects –
Me gustaría lanzar CruiseControl en la mezcla, si aún no lo has considerado. No puedo comentar un punto de vista de Java, habiendo usado la versión de .NET pero me gusta eso. – AdaTheDev
@ire_and_curses ninguna de las respuestas en la publicación da un buen argumento para cualquiera de las herramientas en comparación con la otra – pdeva