Gitlab CI vs Jenkins
¿Puede alguien por favor dejarme saber cuál es la diferencia entre Jenkins y otros CI como Gitlab-CI, drone.io viene con la distribución GIT. En algunas investigaciones, solo pude pensar que Gitlab community edition no permite que se agregue Jenkins, pero Gitlab enterprise edition sí. ¿Hay alguna otra diferencia significativa?
2 answers
Esta es mi experiencia:
En mi trabajo gestionamos nuestros repositorios con gitlab ee y tenemos un servidor Jenkins (1.6) en ejecución.
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 plugin
- Jenkins tiene una interfaz gráfica de usuario (esto se puede preferir si tiene que ser accesible/mantenible por otras personas)
- Integración con GitLab es menor que con Gitlab-ci
- Jenkins se puede dividir de su repo
La mayoría de los servidores CI son bastante sencillos ( concourse.ci, gitlab-ci, circle-ci, travis-ci, drone.io, gocd y qué más tienes). Le permiten ejecutar 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 desventaja, dependiendo de su requiere.
Jenkins es muy configurable debido a todos los plugins 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 (llamando a comandos curl). Además, Jenkins soporta plugins que instalarán ciertos binarios cuando no estén disponibles en tu servidor (no lo sabes para los demás).
Hoy en día (jenkins2 también soporta más "ci apropiado" con el complemento Jenkinsfile y el complemento pipline que viene por defecto como de Jenkins 2), pero solía estar menos acoplado al repositorio que gitlab ci.
Usar archivos yaml para definir su canalización de compilación (y al final ejecutar pure shell/bat) es más limpio.
EDIT: lo que olvidé mencionar aquí son los plug-ins disponibles para Jenkins que 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 estos informes demasiado)
EDIT2: Últimamente he estado trabajando más y 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 funcionando y disponible es muy fácil comenzar con Gitlab-ci. No habrá nada que se integre tan perfectamente como Gitlab-ci, a pesar de que pusieron bastante esfuerzo en integraciones de terceros.
- Su documentación debería ayudarte a empezar en poco tiempo
- el umbral para comenzar es muy bajo
- El mantenimiento es fácil (sin plugins)
- escalando corredores es simple
- CI forma parte de su repositorio
- Jenkins trabajos / vistas pueden conseguir desordenado
Algunos beneficios en el momento de escritura
- Solo soporte para un solo archivo, pero eso va a ser arreglado pronto
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-06-27 11:55:32
Estoy de acuerdo con la mayoría de las notas de Rik, pero mi opinión sobre cuál es un más simple es lo opuesto: GitLab está demostrando ser una herramienta impresionante para trabajar.
La mayor parte del poder proviene de ser autocontenido y integrando todo en el mismo producto bajo la misma pestaña del navegador: desde el navegador del repositorio, la placa de emisión o el historial de compilación hasta las herramientas de implementación y monitoreo.
Lo estoy usando ahora mismo para automatizar y probar cómo una aplicación se instala en diferentes distribuciones de Linux y es simplemente increíblemente rápido configurar (intente abrir una configuración compleja de trabajos de Jenkins en firefox y espere a que aparezca el script no sensible frente a lo liviano que es editar .gitlab-ci.yml). El tiempo dedicado a configurar / escalar esclavos es considerablemente menor gracias a los binarios de runner ; además del hecho de que en GitLab.com obtienes corredores compartidos bastante decentes y gratuitos.
Jenkins siente más manual después algunas semanas de ser un usuario avanzado de GitLab CI, por ejemplo, duplicando trabajos por rama, instalando plugins para hacer cosas simples como subir SCP. El único caso de uso al que me he enfrentado en el que lo echo de menos como para hoy es cuando más de un repositorio está involucrado; que necesita ser muy bien resuelto todavía.
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 el primer artículo que presenta la conceptos básicos, pros y contras y diferencias con otras herramientas: https://solidgeargroup.com/gitlab_countinuous_integration_intro
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-08 13:02:37