Hacemos una verificación profunda cada artículo de nuestro sitio web con la meta de enseñarte en todo momento información veraz y actualizada.
Solución:
Esta es mi experiencia:
En mi trabajo, administramos 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 de complementos
- Jenkins tiene una GUI (esto se puede preferir si tiene que ser accesible / mantenible por otras personas)
- La integración con GitLab es menor que con GitLab CI
- Jenkins puede separarse 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 (llamar a los comandos curl). Además, Jenkins admite complementos que instalarán ciertos 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 adecuada” con el Jenkinsfile y 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.
Usar archivos YAML para definir su canalización 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 static analizadores. 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 en ejecución 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 ayudarlo a comenzar en poco tiempo.
- El umbral para empezar es muy bajo.
- El mantenimiento es fácil (sin complementos).
- Escalar corredores es simple.
- CI es completamente parte de su repositorio.
- Los trabajos / vistas de Jenkins pueden ser complicados.
Algunas ventajas al momento de escribir:
- Solo es compatible con un solo archivo en la edición comunitaria. Varios 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 compilación hasta las herramientas de implementación y el monitoreo.
Lo estoy usando ahora mismo para automatizar y probar cómo se instala una aplicación en diferentes distribuciones de Linux, y es simplemente increíblemente rápido de configurar (intente abrir una configuración de trabajo compleja de Jenkins en Firefox y espere a que aparezca el script que no responde en comparación con lo liviano que 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 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 en el que lo echo de menos hoy es cuando hay más de un repositorio involucrado; eso debe estar bien resuelto todavía.
Por cierto, actualmente estoy escribiendo una serie sobre GitLab CI para demostrar cómo no es tan difícil configurar la infraestructura de CI del repositorio con él. 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 completamente interoperable con Jenkins. No hay duda.
A continuación, doy algunos comentarios sobre una experiencia exitosa que combina Jenkins y GitLab CI. También discutiré si debe usar ambos o solo uno de ellos, y por qué razón.
Espero que esto les brinde información de calidad sobre sus propios proyectos.
Puntos fuertes de GitLab CI y Jenkins
GitLab CI
GitLab CI está integrado de forma natural en GitLab SCM. Puede crear canalizaciones usando gitlab-ci.yml archivos y manipularlos a través de una interfaz gráfica.
Obviamente, estas canalizaciones como código se pueden almacenar en la base del código, lo que impone 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 que no son técnicos) tienen acceso rápido y sencillo al estado del ciclo de vida de las aplicaciones.
- por lo tanto, se puede utilizar como interactivo y Operacional panel de control para la gestión de versiones.
Jenkins
Jenkins es una gran herramienta de construcción. Su fuerza está en sus muchos complementos. Especialmente, he tenido 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.
Pipeline como código también está disponible usando groovyguiones.
Usando GitLab CI y Jenkins juntos
Puede parecer un poco redundante al principio, pero combinar GitLab CI y Jenkins es bastante poderoso.
- GitLab CI orquesta (encadena, ejecuta, monitorea …) pipelines 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 tener una sola 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 es necesario tener un nivel mínimo de comprensión de muchas herramientas.
Por esta razón, no recomiendo esta configuración a menos que
- tiene muchas herramientas de terceros con las que lidiar. Ahí es cuando Jenkins resulta muy útil con sus muchos complementos.
- tiene que lidiar con aplicaciones complejas con tecnologías heterogéneas, cada una de las cuales tiene un entorno de compilación diferente, y aún necesita tener una interfaz de usuario de administración del ciclo de vida de la aplicación unificada.
Si no se encuentra en ninguna de estas situaciones, probablemente esté mejor con solo uno de los dos, pero no ambos.
Si tuviera que elegir uno
Tanto GitLab CI como Jenkins tienen pros y contras. Ambos son herramientas poderosas. Entonces, ¿cuál elegir?
respuesta 1
Elija aquel en el que su equipo (o alguien cercano) ya tenga cierto nivel de experiencia.
Respuesta 2
Si es un estudiante de primer año completo en tecnologías de CI, solo elija una y comience.
- Si está utilizando GitLab y tiene un don para todo como código, tiene total sentido elegir GitLab CI.
- Si tiene que dialogar con muchas otras herramientas de CI / CD o necesita absolutamente esa GUI para crear sus trabajos, elija Jenkins.
Aquellos de ustedes que están usando GitLab y no están seguros de seguir haciéndolo, deben tener en cuenta que, haber elegido GitLab CI implicaría tirar a la basura todas sus canalizaciones de CI / CD.
La última palabra es: la balanza se inclina poco poco hacia Jenkins debido a sus muchos complementos, pero es probable que GitLab CI cubra rápidamente el vacío.
Reseñas y calificaciones del tutorial
Si conservas alguna indecisión o forma de arreglar nuestro sección puedes realizar una observación y con gusto lo estudiaremos.