¿Hudson o Teamcity para una integración continua? [cerrado]

100

Somos una tienda de Java que busca una herramienta de CI para utilizar. Tanto Hudson como Teamcity parecen ser gratuitos, pero Teamcity parece más hábil y con más soporte.

Me preguntaba por qué uno todavía usaría Hudson y si alguien podría proporcionar algún argumento a favor / en contra de cualquiera de ellos.

pdeva
fuente
Puede que le interesen las respuestas aquí: stackoverflow.com/questions/1200721/…
ire_and_curses
Lanzaría CruiseControl a la mezcla, si aún no lo ha considerado. No puedo comentar sobre el punto de vista de Java, habiendo usado la versión .NET, pero eso me gusta.
AdaTheDev
3
@ire_and_curses ninguna de las respuestas en la publicación da un buen argumento para ninguna de las herramientas en comparación con la otra
pdeva
4
-1 para Cruise Control - WAY demasiados archivos de configuración que necesitan ser configurados manualmente "sólo así".
Bevan
3
Por lo que puedo ver, la existencia de TeamCity gratuito hace que CruiseControl desaparezca. No veo ninguna razón para usar CruiseControl en TeamCity. Y muchas razones para lo contrario.
Niall Connaughton

Respuestas:

113

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, cuándo un archivo que está editando en el IDE se vuelve obsoleto, quién lo cambió y qué cambió. Puede comprometerse desde el IDE al servidor de CI, ejecutar la compilación y las pruebas en la cuadrícula de compilación, y luego el servidor de CI se comprometerá si la compilación es exitosa. Puede hacer clic en crear informes en la aplicación web de CI y se abrirán los archivos correspondientes en el IDE.

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

Nat
fuente
9
La ejecución remota / confirmación pre-probada 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 recibe comentarios continuos sobre lo que sucede en su compilación (cuántas pruebas pasaron, fallaron, en qué etapa se encuentra la compilación, etc.). Además, 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 Sher
6
@Pavel: No conozco TeamCity tan bien como Hudson, así que no cuestionaré el comienzo de tu 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 wiki.hudson-ci.org/display/HUDSON/Plugins ) y estoy seguro de que TC tiene más limitaciones que Hudson.
Pascal Thivent
3
Estoy de acuerdo con los canales (Hudson tiene muchos complementos), pero no estoy de acuerdo con las reglas. En TeamCity puede suscribirse a las compilaciones con sus cambios, puede optar por recibir una notificación cuando la compilación comience a fallar (por ejemplo, cuando la primera prueba comience a fallar). Puede solicitar ser notificado sobre la primera compilación fallida después de la secuencia de éxito + sobre 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 sale mal, recibirá una notificación en su IDE. Según recuerdo, las reglas de notificación de Hudson eran mucho más simples.
Pavel Sher
2
Pavel: no quiere una coincidencia de honda aquí, pero de forma predeterminada, Hudson solo le enviará un correo electrónico si contribuyó a la compilación fallida. También puede suscribirse para recibir información sobre cada compilación fallida si lo desea. También hay más opciones en el complemento email-ext. No tiene que aprobarlo, pero no lo tergiverdemos.
Jim T
4
Un rápido google le mostrará que hay complementos para controlar conejos nabaztag y otros dispositivos lindos de Team City. O puede usar el complemento al que me vinculé en mi respuesta . El beneficio de una estrecha integración IDE es una retroalimentación mucho más rápida y enfocada sobre el código en el que está trabajando mientras trabaja con él. No tiene que esperar una notificación, cambiar al navegador tge, leer el informe, volver al IDE y abrir el archivo correspondiente. El panel del editor cambia a medida que trabaja para mostrar cómo otros miembros del equipo han afectado el código.
Nat
58

+1 para 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 comenzar, es fácil de usar, se ha utilizado en proyectos enormes, muy grandes (JBoss, JAX-WS, etc.) y, por lo tanto, tiene un historial probado de éxito, ofrece muy buenos características (por ejemplo, compilar matriz, compilar clústeres, etc.), es de código abierto, tiene muchos complementos ...

Y si el apoyo es realmente una cosa importante, puede obtener soporte comercial desde el Sol . Pero FWIW, nunca enfrenté 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 está buscando 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 alguno comercial).

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

Ingeniero de construcción de Hudson, ingeniero de construcción de CruiseControl, ingeniero de construcción de Bamboo, ingeniero de construcción de TeamCity Tendencias de trabajo

Por supuesto, esto no es un indicador técnico.

Pascal Thivent
fuente
88
¿Quizás TeamCity sea tan fácil de usar que no requiera que nadie específicamente empleado lo configure?
Henrik
3
@Henrik: La interpretación del gráfico anterior queda a su discreción. Pero sí, quizás TeamCity sea mágico.
Pascal Thivent
16
Si contrata a un ingeniero de compilación a tiempo completo para ejecutar su integración continua, ahora tiene dos problemas: 1) Es difícil trabajar con su CI, por lo que sus desarrolladores tendrán dificultades y el conocimiento se sentará en la cabeza de esta persona. 2) ¡Estás pagando a alguien para que haga un trabajo que no debería ser necesario!
Niall Connaughton
15
Si estuviera seleccionando un servidor de CI, elegiría el que tuviera MENOS vacantes de trabajo para que un ingeniero dedicado lo administrara. Es una herramienta de desarrollo y los desarrolladores deberían poder administrarla ellos mismos. Si no pueden, necesita una herramienta diferente o desarrolladores diferentes.
Nat
El gráfico de tendencias laborales no implica +1 para Hudson en absoluto ...
Sharique Abdullah
17

Comenzamos con Hudson para un par de proyectos 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 regreso a Hudson. Las principales razones son: - La vibrante comunidad de Hudson, mejor que el apoyo. - La gran cantidad de complementos para todo tipo de tareas. - El código abierto. - Hudson es gratis, TeamCity solo es gratis para 10 proyectos.

editar: TeamCity ahora es gratis para 20 proyectos.

subotnik
fuente
2
Las 10 restricciones del proyecto han disminuido, el único límite ahora es de 20 configuraciones de construcción. Para proyectos pequeños o medianos, tal vez sea suficiente.
fresnos
4
Por curiosidad, ¿qué funciones que estaban disponibles a través de los complementos de Jenkins faltaban en el mundo de TeamCity?
Behrang Saeedzadeh
14

TeamCity es genial porque permite a cada desarrollador tener su propio perfil de compilación y conectarse a él desde su IDE. Que un solitario es 'patear traseros'. También hay soporte para GIT, etc. En serio, échale un vistazo. La versión profesional es gratuita.

Beaumont Muni
fuente
5
GIT también es compatible con Jenkins / Hudson
CJBrew
14

El mayor argumento contra Hudson es que cada lanzamiento introduce 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 la implementación continua en nuestra tienda (cuando registras 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 simplemente por el costo de los errores de Hudson.

jdtangney
fuente
8
El hecho de que haya una actualización disponible no significa que deba actualizar. Prefiero que se publiquen con más frecuencia que con menos frecuencia. Es mi elección cuándo actualizar y ciertamente no lo hago todas las semanas. Además, los mantenedores son muy conservadores sobre la compatibilidad con versiones anteriores. Los complementos generalmente no requieren la última versión de Hudson para funcionar. De hecho, 130 complementos disponibles ahora están construidos con versiones de Hudson que tienen más de un año. Si todavía está preocupado, hay un complemento de reversión automatizado en proceso ..;)
Christopher Orr
1
Desde mi experiencia, el problema es más con los complementos que con el propio Hudson, aunque esto no hace una gran diferencia desde el punto de vista del usuario. 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 lanzamiento y no usar la última versión no es un problema para nosotros: "Si no está roto, no lo arregles" .
Pascal Thivent
2
Cuando el autor principal envía un mensaje diciendo que se ha solucionado una falla de seguridad importante, esa es una razón para actualizar. Mi punto sigue en pie: Hudson es demasiado sencillo, incluso sin complementos adicionales instalados.
jdtangney
1
Puedo decir que después de un año y medio de usar Hudson / Jenkins en un proyecto, si bien es una gran herramienta, nosotros también experimentamos una calidad inconsistente entre lanzamientos, y solo actualizamos cuando era absolutamente necesario. Encontramos soluciones alternativas, incluida la copia de seguridad frecuente de la configuración. Espero probar TeamCity en mi último proyecto.
JaysonRaymond
4
¿Por qué las actualizaciones y la estabilidad deberían ser factores opuestos? ¿No indica eso una falta de calidad?
Niall Connaughton
6

Realmente me gustó Teamcity, pero en el entorno en el que lo 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 tomó migrar todo a Hudson.

sal
fuente
10
TeamCity professional es gratuito.
Pavel Sher
6
@Pavel, tenemos más de 20 usuarios y muchas más compilaciones que eso.
sal
22
@sal siempre me sorprende cómo las empresas pueden estar tan preocupadas por un par de miles de dólares por las herramientas de sus equipos de desarrollo y preferir que desperdicien cientos de horas combinadas que no habrían tenido con la herramienta.
Chris Marisic
5
@Chris ¿Qué pasa si comienzan con una herramienta gratuita de código abierto porque solo para ver cómo funciona algo y 2 años después darse cuenta de que todavía funciona sin ningún problema? ¿Seguiría sugiriendo gastar un par de miles de dólares para actualizar a una herramienta comercial que probablemente haga exactamente lo mismo?
stefanB
1
@stefan Si ha utilizado una herramienta durante 2 años y satisface sus necesidades a menos que haya featureX que necesita de otra herramienta, ¿por qué cambiaría a otra herramienta gratuita o de pago?
Chris Marisic
2

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 hábil 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 al registro en el que puede probar el código antes de registrarlo en el control de código fuente y lo bueno de Jenkins es que es completamente gratuito incluso si supera los 10 usuarios y agentes de compilación.

runxc1 Bret Ferrier
fuente
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!
Danny Gloudemans
Si está de acuerdo con un comentario, vote por él :)
runxc1 Bret Ferrier
1

Estoy empezando a acostumbrarme a hudson listo para experimentar y ver cómo encaja en nuestro entorno actual. No tengo absolutamente ninguna experiencia con Teamcity, así que no puedo comentar sobre eso, pero estoy disfrutando trabajando con Hudson hasta ahora.

Hay muchos complementos para hudson y el sitio de hudson le brinda muchos consejos para escribir los suyos propios ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

Jake Worrell
fuente
1

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

drekka
fuente
Después de un uso extensivo de TeamCity, Jenkins se ve muy desnudo. Sí, los complementos te permiten hacer cualquier cosa, una vez que los instalas. TeamCity tiene un conjunto de características maduras que lo ponen en marcha de forma inmediata. Sin embargo, en el nivel de entrega continua, ambos dejan sin implementar una tubería de preparación adecuada. QuickBuild es un producto aún más rico en funciones que merece atención, es de pago.
bbaassssiiee
Habiendo visto Bamboo en acción en el sitio de un cliente, ya no me gusta mucho. Hay algunas áreas en torno a la creación de scripts y la transferencia de información entre compilaciones que le cuesta 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