Lanzamiento y visualizaci贸n de canalizaciones al configurar GitLab CI / CD para varios proyectos.
La integraci贸n continua (CI) es la pr谩ctica de automatizar el ensamblaje y las pruebas de c贸digo antes de que se fusione con la rama principal. Permite a los desarrolladores inyectar c贸digo con bastante frecuencia y de manera temprana, al tiempo que reduce el riesgo de introducir nuevos errores en el repositorio principal de c贸digo fuente.
Aunque CI verifica que el nuevo c贸digo no se rompa cuando se integra con otro c贸digo en el mismo repositorio, pasar todas las pruebas en este repositorio es solo el primer paso. Despu茅s de ejecutar CI en el c贸digo, es importante implementar y ejecutar pruebas en un entorno real. La transici贸n de CI a Entrega e implementaci贸n continua (CD) es el siguiente paso para el DevOps "adulto". La implementaci贸n y las pruebas posteriores le permiten probar el c贸digo de un proyecto junto con otros componentes y servicios que pueden ser gestionados por otros proyectos.
驴Por qu茅 debo asegurarme de que mi c贸digo funciona con otros componentes?
Un buen ejemplo es la arquitectura de microservicios. Por lo general, los microservicios se administran en diferentes proyectos , donde cada microservicio tiene su propio repositorio con una tuber铆a. Adem谩s, muy a menudo cada equipo de desarrollo es responsable de microservicios individuales y configuraciones de tuber铆as. Como programador, es posible que desee asegurarse de que los cambios en su c贸digo no violen la funcionalidad de sus microservicios. Por lo tanto, puede ejecutar pruebas en ellos adem谩s de las pruebas para su proyecto.
Proyecto de tuber铆a cruzada
Al comenzar una tuber铆a de proyecto, tambi茅n deber谩 ejecutar una tuber铆a de proyecto cruzado, que eventualmente implementar谩 y probar谩 la 煤ltima versi贸n de todos los microservicios dependientes. Para lograr esto, necesita una forma simple, flexible y conveniente de lanzar otras canalizaciones dentro del marco del CI de su proyecto. GitLab CI / CD ofrece una manera f谩cil de iniciar una canalizaci贸n de proyectos cruzados al agregar una tarea especial al archivo de configuraci贸n de CI.
Archivo de configuraci贸n de GitLab CI / CD
En GitLab CI / CD, las canalizaciones, as铆 como los trabajos y los pasos de sus componentes se definen en el .gitlab-ci.yml para cada proyecto. El archivo es parte del repositorio del proyecto. Est谩 completamente versionado, y los desarrolladores pueden editarlo usando cualquier IDE de su elecci贸n. No necesitan pedirle al administrador del sistema o al comando DevOps que realicen cambios en la configuraci贸n de la canalizaci贸n, ya que pueden hacerlo ellos mismos. El .gitlab-ci.yml determina la estructura y el orden de las tuber铆as, y decide qu茅 se debe hacer con GitLab Runner (el agente que ejecuta las tareas), y qu茅 decisiones se deben tomar cuando surgen ciertas condiciones, por ejemplo, cuando el proceso se completa con 茅xito o sale sistema
Agregar trabajo para ejecutar una tuber铆a entre proyectos
Comenzando con GitLab 11.8, GitLab proporciona una nueva sintaxis de configuraci贸n de CI / CD para ejecutar canalizaciones entre proyectos, que se puede encontrar en las reglas de configuraci贸n de canalizaci贸n . El siguiente c贸digo ilustra c贸mo configurar un trabajo de puente para ejecutar una tuber铆a de enlace descendente:
// job1 job deploy: stage: Deploy script: this is my script // job2 bridge job , - Android: stage: Trigger-cross-projects trigger: mobile/android
En el ejemplo anterior, tan pronto como el trabajo de implementaci贸n en la etapa de implementaci贸n es exitoso, comienza la tarea para el puente de Android. Su estado inicial estar谩 pendiente. GitLab crear谩 una tuber铆a descendente en el proyecto m贸vil / Android, y una vez que se cree, el trabajo de Android tendr谩 茅xito. En este caso, m贸vil / Android es el camino completo a este proyecto.
El usuario que cre贸 la canalizaci贸n ascendente debe tener derechos de acceso al proyecto descendente (en este caso, m贸vil / android). Si no se puede encontrar el proyecto posterior o el usuario no tiene derechos de acceso para crear una tuber铆a all铆, el trabajo de Android recibir谩 el estado fallido.
Descripci贸n general de los gr谩ficos de la tuber铆a ascendente a descendente
GitLab CI / CD le permite visualizar la configuraci贸n de la tuber铆a. En la figura siguiente, los pasos de montaje, prueba e implementaci贸n son parte de un proyecto ascendente. Una vez que el trabajo de implementaci贸n se haya completado con 茅xito, se lanzar谩n cuatro proyectos cruzados en paralelo, y puede continuar con ellos haciendo clic en uno de los trabajos posteriores.
En la figura a continuaci贸n puede ver la l铆nea de pago descendente "Servicio - Finanzas". Ahora puede desplazarse hacia la izquierda hacia la tuber铆a ascendente, desplazarse hacia la derecha hacia la tuber铆a descendente o seleccionar otra tuber铆a descendente.
Definir una rama de tuber铆a secundaria
Puede especificar el nombre de la rama que usar谩 la tuber铆a descendente:
trigger: project: mobile/android branch: stable-11-2
Use la palabra clave del proyecto para indicar la ruta completa al proyecto posterior. Use la palabra clave branch para determinar el nombre de la rama. GitLab usar谩 el commit que se encuentra actualmente en la rama HEAD al crear la tuber铆a de enlace descendente.
Pasar variables a una tuber铆a descendente
Alg煤n d铆a, es posible que desee pasar variables a una tuber铆a descendente. Puede hacer esto con palabras clave para variables, como lo har铆a con una definici贸n de trabajo regular.
Android: variable: ENVIRONMENT: 'This is the variable value for the downstream pipeline' stage: Trigger-cross-projects trigger: mobile/android
La variable ENTORNO se pasar谩 a cada trabajo definido en la tuber铆a descendente. Estar谩 disponible como una variable de entorno cada vez que GitLab Runner seleccione un trabajo.
Tuber铆a total de proyectos cruzados
El .gitlab-ci.yml determina el orden de las etapas de CI / CD, qu茅 tareas realizar y en qu茅 condiciones iniciar u omitir la tarea. Agregar un 'trabajo de puente' con la palabra clave de trigger a este archivo puede usarse para ejecutar canalizaciones entre proyectos. Podemos pasar par谩metros a trabajos en tuber铆as descendentes e incluso definir la rama que utilizar谩 la tuber铆a descendente.
Las tuber铆as pueden ser estructuras complejas con muchas tareas secuenciales y paralelas y, como acabamos de aprender, a veces pueden correr tuber铆as aguas abajo. Para simplificar la comprensi贸n del flujo de la tuber铆a, incluidas las tuber铆as descendentes, GitLab tiene tuber铆as para ver las tuber铆as y sus estados.
Lea tambi茅n otros art铆culos en nuestro blog: