continuous integration - delivery - ¿Cómo elegir entre Hudson y Jenkins?
hudson vs jenkins (8)
Como escribió chmullig , usa a Jenkins . Algunos puntos adicionales:
De hecho, podría decirse que fue Oracle quien hizo la bifurcación . Y técnicamente, también, eso es un poco lo que pasó .
Es interesante ver lo que sale de "Hudson" sin embargo. Mientras que "Winston resume el estado y el futuro prometedor del proyecto de Hudson", las cosas que publicaron en el (nuevo) sitio web de Hudson originalmente me parecieron un humor extraño, tal vez fue una adquisición intencional, y los chicos de Sonatype realmente tienen algunas grandes ideas. su manga Este análisis , que sugiere una estrategia deliberada de Oracle / Sonatype para expulsar a Kohsuke y su equipo para crear una Hudson más "emprendedora" es una lectura muy interesante.
En cualquier caso, esta breve comparación quince días después de la división, aunque no es exactamente científica, muestra a Jenkins como uno de los proyectos mucho más activos.
... y un poco de información de fondo:
El creador de Hudson, Kohsuke Kawaguchi , comenzó el proyecto en su tiempo libre, incluso si trabajaba para Sun Microsystems y luego pagó por ellos para desarrollarlo aún más. Como @erickson señaló en otra pregunta de SO ,
[Hudson / Jenkins] es el producto de un solo intelecto genio: Kohsuke Kawaguchi. Por eso, es consistente, coherente y sólido como una roca.
Después de la adquisición por parte de Oracle, Kohsuke no se quedó mucho tiempo ( debido a la falta de monitores ...?; -] ), y se fue a trabajar para CloudBees . Lo que comenzó a fines de 2010 como conflicto por las herramientas entre la comunidad de desarrolladores y Oracle y terminó en renombrar / dividir / dividir está bien documentado en los enlaces proporcionados por chmullig. Para mí, todo ese enigma habla, quizás más que cualquier otra cosa, de la total incapacidad o falta de voluntad de Oracle para patrocinar un proyecto de código abierto de una manera que mantenga a todas las partes (Oracle, desarrolladores, usuarios) felices. No está en su ADN o algo así, como hemos visto en other cases también.
Teniendo en cuenta todo lo anterior, personalmente seguiría a Kohsuke y otros desarrolladores principales en este asunto, e iría con Jenkins.
Me tomó más o menos una hora para que Hudson se haya bifurcado recientemente (enero / 2011)
No tengo idea de lo rápido que es el cambio de cada rama ahora, pero lo que es más importante, ¿cuál es la dirección que está tomando cada rama y cuáles son los puntos clave para que uno pueda elegir entre cuál ir?
¿Alguien tiene enlaces a la hoja de ruta del producto y las diferencias de características?
Desde el sitio web de Jenkins, Jenkins , a continuación se resume.
En pocas palabras, Jenkins CI es el principal servidor de integración continua de código abierto. Construido con Java, proporciona más de 300 complementos para ayudar a construir y probar prácticamente cualquier proyecto.
Oracle ahora posee la marca registrada Hudson, pero la ha otorgado bajo el Eclipse EPL . Jenkins está en la licencia MIT . Tanto Hudson como Jenkins son de código abierto. En base a la combinación de para quién trabaja y la preferencia personal por el código abierto, la decisión es sencilla IMHO.
Espero que esto haya sido útil.
En el frente ... Soy un comentarista de Hudson y autor del libro de Hudson, pero no estuve involucrado en toda la división de los proyectos.
En cualquier caso, aquí está mi consejo:
Echa un vistazo a ambos y ver lo que mejor se adapte a sus necesidades.
Hudson completará la migración para ser un proyecto de Eclipse de alto nivel a finales de este año y ha conseguido un montón de desarrolladores a tiempo completo, control de calidad y otros que trabajan en el proyecto. Sigue siendo fuerte y tiene muchos usuarios y, al ser el servidor de CI predeterminado en Eclipse, continuará satisfaciendo las necesidades de muchos desarrolladores de Java. Mirando la hoja de ruta y los planes para el futuro, puede ver que después de la integración de Maven 3 realizada con la versión 2.1.0, hay muchas otras características interesantes por delante.
Jenkins en el otro lado ha ganado a muchos usuarios originales de Hudson y tiene una gran comunidad de usuarios en múltiples tecnologías y también tiene un montón de desarrolladores trabajando en ello.
En esta etapa, ambos servidores de CI son excelentes herramientas para usar y, dependiendo de sus necesidades, en términos de tecnología para integrarse con uno u otro, podría ser mejor. Ambos productos están disponibles como fuente abierta y puede obtener soporte comercial de varias compañías para ambos.
En cualquier caso ... si aún no está utilizando un servidor CI ... comience ahora con cualquiera de ellos y verá enormes beneficios.
Actualización de enero de 2013: después de un largo proceso de limpieza de IP y mejoras adicionales, Hudson 3.0 como la primera versión aprobada de Eclipse Foundation ya está disponible.
Jenkins es el nuevo Hudson. Realmente es más como un cambio de nombre, no como una bifurcación, ya que toda la comunidad de desarrollo se mudó a Jenkins. (Oracle se queda sentado en una esquina con su vieja bola "Hudson", pero ahora es un proyecto sin alma).
Cf Ethereal -> WireShark
Para aquellos que han mencionado la reconciliación como un futuro potencial para Hudson y Jenkins, con el hecho de que Jenkins se unirá a SPI , es poco probable que en este punto se reconcilien.
Solo mi opinión sobre el asunto, tres meses después:
Jenkins ha seguido el camino recorrido por el Hudson original con lanzamientos frecuentes que incluyen muchas actualizaciones menores.
Oracle parece haber delegado en gran medida el trabajo en el camino futuro de Hudson al equipo de Sonatype, que ha realizado algunos cambios significativos, especialmente con respecto a Maven. Lo han trasladado conjuntamente a la fundación Eclipse.
Sugeriría que si te gusta el sonido de:
- las versiones menos frecuentes, pero las que están más probadas para la compatibilidad con versiones anteriores (más de un ciclo de lanzamiento de "estilo empresarial")
- un producto centrado principalmente en una fuerte integración de Maven y / o Nexus (es decir, no tiene interés en Gradle y Artifactory, etc.)
- Ofertas de soporte profesional de Sonatype o quizás Oracle en lugar de Cloudbees, etc.
- no te importa tener una comunidad más pequeña de desarrolladores de plugins, etc.
, entonces sugeriría a Hudson.
A la inversa, si lo prefiere:
- actualizaciones más frecuentes, incluso si requieren ajustes un poco más frecuentes y quizás sean un poco más riesgosos en términos de compatibilidad (más de un ciclo de lanzamiento "más reciente y mejor")
- un sistema con soporte comunitario más activo para, por ejemplo, otros sistemas de compilación / repositorios de artefactos
- Ofertas de apoyo del creador original et al. y / o no te interesa el soporte profesional (p. ej., estás contento siempre y cuando puedas obtener una solución en el "último y mejor" de la próxima semana)
- Una creación clásica de brujas de estilo OSS de un ecosistema de desarrollo.
Entonces sugeriría a Jenkins. (y como comentó un comentarista, Jenkins ahora también tiene versiones "LTS" que se mantienen en una rama más "estable")
El curso conservador sería elegir Hudson ahora y migrar a Jenkins si las funciones imprescindibles no están disponibles. El curso dinámico sería elegir Jenkins ahora y migrar a Hudson si la búsqueda de actualizaciones se vuelve demasiado lenta para justificar.
Tengo dos puntos que añadir. Uno, Hudson / Jenkins tiene que ver con los complementos. Los desarrolladores de plugins se han mudado a Jenkins y nosotros también deberíamos hacerlo nosotros, los usuarios. Dos, personalmente no soy un gran fan de los productos de Oracle. De hecho, los evito como la plaga. Para el dinero gastado en licencias y hardware para una solución Oracle, puede contratar el doble de personal de ingeniería y aún le queda algo para comprar cerveza todos los viernes :)
Usa Jenkins .
Jenkins es la bifurcación reciente de los desarrolladores principales de Hudson. Para entender por qué, necesitas saber la historia del proyecto. Originalmente era de código abierto y soportado por Sun. Como gran parte de lo que hizo Sun, estaba bastante abierto, pero hubo un poco de negligencia benigna. Sun alojó la fuente, los rastreadores, el sitio web, etc. en su plataforma java.net relativamente cerrada.
Entonces Oracle compró Sun. Por diversas razones, Oracle no ha sido tímido al aprovechar lo que percibe como sus activos. Esos incluyen cierto control sobre la plataforma logística de Hudson, y particularmente el control sobre el nombre de Hudson. Muchos usuarios y colaboradores no se sentían cómodos con eso y decidieron irse.
Así que todo se reduce a lo que Hudson vs Jenkins ofrece. Tanto Oracle''s Hudson como Jenkins tienen el código. Hudson tiene el soporte corporativo de Oracle y Sonatype y la marca. Jenkins tiene la mayoría de los desarrolladores centrales, la comunidad y (hasta ahora) mucho más trabajo real.
Lee la publicación que vinculé arriba, then read el resto en order cronológico . Para equilibrar puedes leer el Hudson / Oracle asumirlo . Me queda bastante claro quién está jugando a la defensiva y quién tiene intenciones reales para el proyecto.