En 2011 la situación con Hudson y Jenkins seguía (en mi humilde opinión): Hudson era un poco estable, pero el desarrollo de Jenkins fue un poco más rápido.
¿Cuál es la situación con "Hudson vs Jenkins" ahora en 2012?
Francamente, si fuera usted, invertiría algún tiempo en migrarlo a Jenkins. Tenemos entre 300 y 400 empleos y la migración no fue tan fácil como esperaba, pero no fue algo que no pude manejar en un día. Quizás los muchachos de Jenkins han suavizado el proceso de migración hoy en día, pero, sin embargo, no debería ser una molestia.
carlspring
224
¡Argh! ¡Dejen de "cerrados como no constructivos" ustedes fascistas! Estoy harto de encontrar preguntas. Realmente quiero que la respuesta más popular me guste, solo para ver que están cerradas. Escuché tus podcasts desde el primer episodio, así que entiendo lo que intentas hacer, pero esto es demasiado pesado. ¡Al menos mueva la pregunta al sitio de Programmers SE y ponga un enlace aquí!
Ruibarbo
23
@ Ruibarbo ¡Ojalá pudiera darte 100 votos a favor por tu comentario!
Stefan Haberl
10
Estoy totalmente contigo, Stefan y Ruibarbo!
fazineroso
8
Como todavía hay un interés creciente en las respuestas a este tema (en función del número de puntos de vista y votos a favor de ambas respuestas), me gustaría recomendar un voto para
reabrirlo
Respuestas:
62
En términos de estabilidad, durante más de un año, Jenkins ha ofrecido una versión de soporte a largo plazo (LTS) para las personas que desean estar más seguros de la estabilidad y el soporte del software que están instalando.
Cada tres meses más o menos, se selecciona una versión anterior que la comunidad de usuarios de Jenkins ha considerado que funciona bien. Esta versión se ramifica, las correcciones importantes (que han sido "probadas en batalla") se incluyen en esta versión de Jenkins, y luego esta versión recibe pruebas adicionales de varias personas y compañías. Una vez que está listo para su lanzamiento, se convierte en la nueva versión LTS.
A medida que aparecen nuevas correcciones de alta prioridad, estas se incorporan a la versión LTS.
Esto debería significar que la versión LTS que está descargando es aún más estable que una versión aleatoria elegida de la línea de lanzamiento semanal habitual.
Más allá de las estadísticas, la situación con respecto al uso de Jenkins, el tamaño de la comunidad, su nivel de desarrollo, la tasa de nuevas características agregadas, el número de nuevos complementos y la actividad de la lista de correo en comparación con Hudson no parece haber cambiado (es decir, Jenkins sigue siendo aún más) por delante ).
Básicamente, la mayoría de los puntos planteados en esta discusión anterior todavía se aplican, aunque el apoyo corporativo inicial de Hudson parece haber disminuido un poco.
He usado tanto a Hudson como a Jenkins. He estado siguiendo ambas listas de cambios.
Todavía creo que tomamos la decisión correcta al pasar de Hudson a Jenkins. Los desarrolladores principales de Hudson ahora están trabajando en Jenkins. Los que todavía están empleados por Oracle son los que principalmente apoyan a Hudson (hasta donde yo sé, la gente de Apache Maven también está aportando soluciones).
He presentado varios errores en la era de Hudson. Puedo decirte que la mayoría de ellos se resolvieron en Jenkins. Muchos meses después de su resolución, la gente de Hudson arregló o solicitó más información sobre esos errores particulares.
La mayoría de los desarrolladores de complementos (casi todos, es decir) han migrado sus complementos a Jenkins y ahora son compatibles principalmente con Jenkins. En términos de complementos, Jenkins se está desarrollando mucho, mucho más rápido. Ahora hay algunos complementos pagos proporcionados por Cloudbees.
Hasta donde yo sé, la comunidad de código abierto se ha mudado en su mayoría a Jenkins.
Algunas compañías que prefieren tener soporte pagado y no quieren la molestia de migrar a Jenkins todavía usan Hudson. Francamente, no veo por qué. Jenkins también tiene soporte comercial de Cloudbees, que es donde ahora trabaja Kohsuke Kawaguchi (el creador de Hudson). Cloudbees ahora incluso tiene un servicio gratuito para alojar proyectos alojados en GitHub en su nube. ¡Permiten que sus proyectos de OSS se creen gratis! :)
Jenkins ha mejorado su soporte para la nube. Como se mencionó anteriormente, Cloudbees también proporciona este SaaS en la nube. No estoy seguro de si Hudson y hasta qué punto lo apoya. Creo que no están tan avanzados en este momento; En cualquier caso, Hudson no proporciona un SaaS para la nube, que yo sepa.
Mi opinión es que si tienes que elegir uno, debería ser Jenkins.
Creo que https://stackoverflow.com/a/5970813/556520 responde muchas preguntas importantes sobre el tema de hudson vs jenkins. El tema explica ambos lados de la situación con pros y contras para cada producto.
Por experiencia personal trabajando con CI durante años, y recientemente comencé a desarrollar para Hudson, me quedaría con la versión estable de Hudson solo porque Jenkins está haciendo más desarrollo y soporte para su servicio cloudbees, donde Hudson se ha mudado a la base del eclipse y no desarrollando para un servicio. Eso es solo mis $ 0.02.
Si, gracias. Pero esas respuestas son para 201-2011. La situación podría cambiar en 2012.
Volodymyr Bezuglyy
1
Cloudbees y Jenkins son entidades separadas e independientes. ¿Por qué no seguir con Jenkins que, como mencionas, tiene más funciones, pero opta por la versión estable de LTS?
Christopher Orr
Mientras los desarrollos de cloudbees sean buenos del producto, no entiendo cuál podría ser el problema allí. Con Oracle involucrado, claramente hubo un problema ya que Oracle estaba más preocupado por sus ganancias y menos por la hoja de ruta del producto.
Respuestas:
En términos de estabilidad, durante más de un año, Jenkins ha ofrecido una versión de soporte a largo plazo (LTS) para las personas que desean estar más seguros de la estabilidad y el soporte del software que están instalando.
Cada tres meses más o menos, se selecciona una versión anterior que la comunidad de usuarios de Jenkins ha considerado que funciona bien. Esta versión se ramifica, las correcciones importantes (que han sido "probadas en batalla") se incluyen en esta versión de Jenkins, y luego esta versión recibe pruebas adicionales de varias personas y compañías. Una vez que está listo para su lanzamiento, se convierte en la nueva versión LTS.
A medida que aparecen nuevas correcciones de alta prioridad, estas se incorporan a la versión LTS.
Numerosos usuarios importantes de Jenkins se adhieren a la línea de lanzamientos LTS, y de acuerdo con las estadísticas públicas de uso de Jenkins , varios miles de implementaciones lo están utilizando.
Esto debería significar que la versión LTS que está descargando es aún más estable que una versión aleatoria elegida de la línea de lanzamiento semanal habitual.
Más allá de las estadísticas, la situación con respecto al uso de Jenkins, el tamaño de la comunidad, su nivel de desarrollo, la tasa de nuevas características agregadas, el número de nuevos complementos y la actividad de la lista de correo en comparación con Hudson no parece haber cambiado (es decir, Jenkins sigue siendo aún más) por delante ).
Básicamente, la mayoría de los puntos planteados en esta discusión anterior todavía se aplican, aunque el apoyo corporativo inicial de Hudson parece haber disminuido un poco.
fuente
He usado tanto a Hudson como a Jenkins. He estado siguiendo ambas listas de cambios.
Todavía creo que tomamos la decisión correcta al pasar de Hudson a Jenkins. Los desarrolladores principales de Hudson ahora están trabajando en Jenkins. Los que todavía están empleados por Oracle son los que principalmente apoyan a Hudson (hasta donde yo sé, la gente de Apache Maven también está aportando soluciones).
He presentado varios errores en la era de Hudson. Puedo decirte que la mayoría de ellos se resolvieron en Jenkins. Muchos meses después de su resolución, la gente de Hudson arregló o solicitó más información sobre esos errores particulares.
La mayoría de los desarrolladores de complementos (casi todos, es decir) han migrado sus complementos a Jenkins y ahora son compatibles principalmente con Jenkins. En términos de complementos, Jenkins se está desarrollando mucho, mucho más rápido. Ahora hay algunos complementos pagos proporcionados por Cloudbees.
Hasta donde yo sé, la comunidad de código abierto se ha mudado en su mayoría a Jenkins.
Algunas compañías que prefieren tener soporte pagado y no quieren la molestia de migrar a Jenkins todavía usan Hudson. Francamente, no veo por qué. Jenkins también tiene soporte comercial de Cloudbees, que es donde ahora trabaja Kohsuke Kawaguchi (el creador de Hudson). Cloudbees ahora incluso tiene un servicio gratuito para alojar proyectos alojados en GitHub en su nube. ¡Permiten que sus proyectos de OSS se creen gratis! :)
Jenkins ha mejorado su soporte para la nube. Como se mencionó anteriormente, Cloudbees también proporciona este SaaS en la nube. No estoy seguro de si Hudson y hasta qué punto lo apoya. Creo que no están tan avanzados en este momento; En cualquier caso, Hudson no proporciona un SaaS para la nube, que yo sepa.
Mi opinión es que si tienes que elegir uno, debería ser Jenkins.
fuente
Creo que https://stackoverflow.com/a/5970813/556520 responde muchas preguntas importantes sobre el tema de hudson vs jenkins. El tema explica ambos lados de la situación con pros y contras para cada producto.
Por experiencia personal trabajando con CI durante años, y recientemente comencé a desarrollar para Hudson, me quedaría con la versión estable de Hudson solo porque Jenkins está haciendo más desarrollo y soporte para su servicio cloudbees, donde Hudson se ha mudado a la base del eclipse y no desarrollando para un servicio. Eso es solo mis $ 0.02.
fuente