GitLab CI vs. Jenkins [cerrado]

¿Cuál es la diferencia entre Jenkins y otros CI como GitLab CI, drone.io que viene con la distribución Git? En algunas investigaciones, solo pude llegar a la conclusión de que la edición comunitaria de GitLab no permite que se agregue Jenkins, pero la edición empresarial de GitLab sí. ¿Hay alguna otra diferencia significativa?

Esta es mi experiencia:

En mi trabajo gestionamos nuestros repositorios con GitLab EE y tenemos un servidor Jenkins (1.6) ejecutándose.

En la base, hacen más o menos lo mismo. Ejecutarán algunos scripts en una imagen de servidor / Docker.

TL; DR;

• Jenkins es más fácil de usar / aprender, pero tiene el riesgo de convertirse en un infierno de complementos
• Jenkins tiene una GUI (se puede preferir si otras personas deben tener acceso a ella o mantenerla)
• La integración con GitLab es menor que con GitLab CI
• Jenkins se puede separar de su repositorio

La mayoría de los servidores de CI son bastante sencillos ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd y qué más tienes). Le permiten ejecutar scripts de shell / bat desde una definición de archivo YAML. Jenkins es mucho más conectable y viene con una interfaz de usuario. Esto puede ser una ventaja o una desventaja, según sus necesidades.

Jenkins es muy configurable debido a todos los complementos que están disponibles. La desventaja de esto es que su servidor CI puede convertirse en un espagueti de complementos.

En mi opinión, el encadenamiento y la orquestación de trabajos en Jenkins es mucho más simple (debido a la interfaz de usuario) que a través de YAML (llamadas a comandos curl). Además, Jenkins admite complementos que instalarán ciertos archivos binarios cuando no estén disponibles en su servidor (no lo sé para los demás).

Hoy en día ( Jenkins 2 también admite más "ci apropiado" con el Jenkinsfiley el complemento pipline que viene por defecto a partir de Jenkins 2), pero solía estar menos acoplado al repositorio que, por ejemplo, GitLab CI.

El uso de archivos YAML para definir su canal de compilación (y al final ejecutar shell / bat puro) es más limpio.

Los complementos disponibles para Jenkins le permiten visualizar todo tipo de informes, como resultados de pruebas, cobertura y otros analizadores estáticos. Por supuesto, siempre puede escribir o usar una herramienta para hacer esto por usted, pero definitivamente es una ventaja para Jenkins (especialmente para los gerentes que tienden a valorar demasiado estos informes).

Últimamente he estado trabajando cada vez más con GitLab CI. En GitLab están haciendo un gran trabajo haciendo que toda la experiencia sea divertida. Entiendo que la gente usa Jenkins, pero cuando tienes GitLab ejecutándose y disponible, es realmente fácil comenzar con GitLab CI. No habrá nada que se integre tan fácilmente como GitLab CI, a pesar de que ponen un gran esfuerzo en integraciones de terceros.

• Su documentación debería ayudarlo a comenzar de inmediato.
• El umbral para comenzar es muy bajo.
• El mantenimiento es fácil (sin complementos).
• Escalar corredores es simple.
• CI completamente parte de su repositorio.
• Los trabajos / vistas de Jenkins pueden volverse desordenados.

Algunas ventajas al momento de escribir:

• Solo soporte para un solo archivo en la edición comunitaria. Múltiples archivos en la edición empresarial .

Estoy de acuerdo con la mayoría de las notas de Rik, pero mi opinión sobre cuál es más simple es lo contrario : GitLab está demostrando ser una herramienta increíble para trabajar.

La mayor parte del poder proviene de ser autónomo e integrar todo en el mismo producto en la misma pestaña del navegador: desde el navegador del repositorio, el tablero de problemas o el historial de construcción hasta las herramientas de implementación y monitoreo .

Lo estoy usando en este momento para automatizar y probar cómo se instala una aplicación en diferentes distribuciones de Linux, y es extremadamente rápido de configurar (intente abrir una configuración compleja de trabajo de Jenkins en Firefox y espere a que aparezca el script que no responde vs . cuán liviano es editar .gitlab-ci.yml).

El tiempo dedicado a configurar / escalar esclavos es considerablemente menor gracias a los binarios del corredor ; más el hecho de que en GitLab.com obtienes corredores compartidos bastante decentes y gratuitos.

Jenkins se siente más manual después de algunas semanas de ser un usuario avanzado de GitLab CI, por ejemplo, duplicando trabajos por rama, instalando complementos para hacer cosas simples como la carga de SCP. El único caso de uso al que me he enfrentado y en el que lo echo de menos hoy es cuando hay más de un repositorio involucrado; eso todavía tiene que estar bien resuelto.

Por cierto, actualmente estoy escribiendo una serie sobre GitLab CI para demostrar cómo no es tan difícil configurar su infraestructura de CI de repositorio con ella. Publicado la semana pasada, la primera pieza presenta los conceptos básicos, los pros y los contras y las diferencias con otras herramientas: Integración continua rápida y natural con GitLab CI

En primer lugar, a partir de hoy, GitLab Community Edition puede ser totalmente interoperable con Jenkins. No hay duda.

A continuación, doy algunos comentarios sobre una experiencia exitosa que combina tanto Jenkins como GitLab CI. También discutiré si debe usar ambos o solo uno de ellos, y por qué motivo.

Espero que esto le brinde información de calidad sobre sus propios proyectos.

Fortalezas de GitLab CI y Jenkins

GitLab CI

GitLab CI está naturalmente integrado en GitLab SCM. Puede crear tuberías utilizando gitlab-ci.ymlarchivos y manipularlos a través de una interfaz gráfica.

Estas canalizaciones como código obviamente pueden almacenarse en la base del código, aplicando la práctica de "todo como código" (acceso, control de versiones, reproducibilidad, reutilización, etc.).

GitLab CI es una gran herramienta de gestión visual:

• Todos los miembros de los equipos (incluidos los no técnicos) tienen acceso rápido y fácil al estado del ciclo de vida de las aplicaciones.
• por lo tanto, se puede usar como un tablero interactivo y operativo para la administración de versiones.

Jenkins

Jenkins es una gran herramienta de construcción. Su fuerza está en sus muchos complementos. Especialmente, tuve mucha suerte al usar complementos de interfaz entre Jenkins y otras herramientas de CI o CD. Esta es siempre una mejor opción que volver a desarrollar (posiblemente mal) una interfaz de diálogo entre dos componentes.

La canalización como código también está disponible mediante groovyscripts.

Usando GitLab CI y Jenkins juntos

Puede sonar un poco redundante al principio, pero combinar GitLab CI y Jenkins es bastante poderoso.

• GitLab CI orquesta (encadena, ejecuta, monitorea ...) las tuberías y uno puede beneficiarse de su interfaz gráfica integrada a GitLab
• Jenkins ejecuta el trabajo y facilita el diálogo con herramientas de terceros.

Otro beneficio de este diseño es tener un acoplamiento flojo entre las herramientas:

• podríamos reemplazar cualquiera de los componentes de la fábrica de construcción sin tener que volver a trabajar todo el proceso de CI / CD
• podríamos tener un entorno de compilación heterogéneo, combinando (posiblemente varios) Jenkins, TeamCity, lo que sea, y aún así tener una única herramienta de monitoreo.

La compensación

Bueno, por supuesto, hay un precio que pagar por este diseño: la configuración inicial es engorrosa y debe tener un nivel mínimo de comprensión de muchas herramientas.

Por esta razón, no recomiendo dicha configuración a menos que

• tienes muchas herramientas de terceros con las que lidiar. Es entonces cuando Jenkins es muy útil con sus muchos complementos.
• debe lidiar con aplicaciones complejas con tecnologías heterogéneas, cada una con un entorno de compilación diferente, y aún debe tener una interfaz de usuario unificada para la gestión del ciclo de vida de la aplicación.

Si no se encuentra en ninguna de estas situaciones, probablemente esté mejor con solo una de las dos, pero no con ambas.

Si tuviera que elegir uno

Tanto GitLab CI como Jenkins tienen pros y contras. Ambas son herramientas poderosas. Entonces, ¿cuál elegir?

respuesta 1

Elija el que su equipo (o alguien cercano) ya tiene un cierto nivel de experiencia.

Respuesta 2

Si todos son estudiantes de primer año en tecnologías de CI, simplemente elija uno y comience.

• Si está utilizando GitLab y tiene un don para todo como código, tiene mucho sentido elegir GitLab CI.
• Si tiene que dialogar con muchas otras herramientas de CI / CD o necesita absolutamente esa GUI para construir sus trabajos, vaya a Jenkins.

Aquellos de ustedes que están usando GitLab y no están seguros de que seguirán haciéndolo, deben tener en cuenta que, al elegir GitLab CI, esto implicaría tirar a la basura todos sus canales de CI / CD.

La última palabra es: el equilibrio se inclina un poco hacia Jenkins debido a sus muchos complementos, pero es probable que GitLab CI llene rápidamente la brecha.

Me gustaría agregar algunos hallazgos de mi reciente experimento con GitLab CI. ¡Las características que vienen con 11.6 y 11.7 son simplemente increíbles!

Específicamente, me encantan las onlycondiciones que básicamente le permiten construir tuberías separadas para merge_requesto push(la lista completa está aquí )

Además, me gusta mucho la ausencia de complementos. Cuando necesito una funcionalidad más compleja, solo escribo una imagen Docker personalizada que maneja la funcionalidad requerida (es el mismo concepto que puede ver en drone.io ).

Si te preguntas sobre DRY , ¡es absolutamente posible hoy en día! Puedes escribir tus "plantillas"

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Póngalos en algún repositorio público, inclúyalos en la tubería principal:

include:
  - remote: https://....

Y úsalos para extender algún trabajo:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

¡Amo tanto a GitLab CI! Sí, (hasta ahora) no puede dibujar gráficos agradables con cobertura, etc., pero en general es una herramienta muy buena.

Editar (2019-02-23): aquí está mi publicación sobre cosas que amo en GitLab CI. Fue escrito en 11.7 "era", así que cuando estás leyendo esta respuesta, GitLab CI probablemente tiene muchas más funciones.

Editar (2019-07-10): Gitlab CI ahora admite múltiples, extendspor ejemplo

extends:
 - .pieceA
 - .pieceB

Consulte la documentación oficial para obtener más información sobre extensiones múltiples

si sus trabajos de compilación / publicación / implementación y prueba no son muy complejos, el uso de gitlab ci tiene ventajas naturales.

Dado que gitlab-ci.yml está presente junto con su código en cada rama, puede modificar sus pasos ci / cd, en particular las pruebas (que difieren entre entornos) de manera más efectiva.

Por ejemplo, desea realizar pruebas unitarias para cualquier registro en la rama de desarrollo, mientras que es posible que desee realizar pruebas funcionales completas en la rama de control de calidad y obtener un tipo limitado de pruebas en producción, esto se puede lograr fácilmente usando gitlab ci.

La segunda ventaja, aparte de la gran interfaz de usuario, es su capacidad de usar imágenes de Docker para ejecutar cualquier etapa que mantiene el corredor host intacto y, por lo tanto, menos propenso a errores.

además, gitlab ci se registrará automáticamente por usted y no tendrá que administrar el maestro jenkins por separado