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.yml
archivos 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 groovy
scripts.
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.