En esta charla vamos a presentar una implementación que permite aplicar el modelo de Integración Continua/Despliegue Continuo (_CI/CD_) a repositorios, que pueden o no ser _legacy_, basándonos en un enfoque moderno a través de pipelines de Jenkins implementados con jenkinsfiles. La estrategia propuesta pretende solventar los retos que se plantean al trabajar con monorepositorios de código que albergan múltiples aplicaciones, aportando a la vez un alto grado de flexibilidad y adaptabilidad gracias al modelo de implementación de ese entorno de integración continua que vamos a describir.
¿Por qué nos planteamos hacer esto? La razón para abordar esta implementación parte de reforzar la idea de que no hay una única estrategia válida de gestión de la configuración en la que deba existir una relación 1:1 entre repositorio y aplicación. En el día a día no siempre nos encontramos con proyectos que cuentan con un repositorio de código o conjunto de repositorios de código con la que, a veces, se tiende a considerar, una estructura estándar de gestión de la configuración en la que cada aplicación tiene su repositorio específico (modelo 1:1) organizado en las ramas y etiquetas que se estimen necesarias. Es habitual encontrar el caso en el que la totalidad del código de las aplicaciones del cliente/proyecto se encuentra albergado en un único repositorio de código (monorepositorio en el modelo 1:N) estructurado de tal forma que todas las aplicaciones están distribuidas en diferentes carpetas organizadas siguiendo diversos criterios, habitualmente propios y específicos de ese cliente/proyecto.
Tanto el modelo repo-app 1:1 como el modelo 1:N presentan pros y cons y existe una motivación detrás de cada una de estas opciones: una gestión del ciclo de vida de CI/CD en el que los pipelines deben respetar las interdependencias existentes entre las diferentes aplicaciones del monorepositorio en cuestión es una razón de peso para considerar dicho modelo como el adecuado. Y todo esto nos plantea retos en cuanto a la generación de una definición de integración continua que se adapte a esta casuística descrita en la que múltiples aplicaciones comparten un único repositorio y cuyo ciclo de vida debe orquestarse atendiendo a la interdependencia entre ellas.
En esta charla vamos a presentar una implementación que permite aplicar el modelo de Integración Continua/Despliegue Continuo (_CI/CD_) a repositorios, que pueden o no ser _legacy_, basándonos en un enfoque moderno a través de pipelines de Jenkins implementados con jenkinsfiles. La estrategia propuesta pretende solventar los retos que se plantean al trabajar con monorepositorios de código que albergan múltiples aplicaciones, aportando a la vez un alto grado de flexibilidad y adaptabilidad gracias al modelo de implementación de ese entorno de integración continua que vamos a describir.
¿Por qué nos planteamos hacer esto? La razón para abordar esta implementación parte de reforzar la idea de que no hay una única estrategia válida de gestión de la configuración en la que deba existir una relación 1:1 entre repositorio y aplicación. En el día a día no siempre nos encontramos con proyectos que cuentan con un repositorio de código o conjunto de repositorios de código con la que, a veces, se tiende a considerar, una estructura estándar de gestión de la configuración en la que cada aplicación tiene su repositorio específico (modelo 1:1) organizado en las ramas y etiquetas que se estimen necesarias. Es habitual encontrar el caso en el que la totalidad del código de las aplicaciones del cliente/proyecto se encuentra albergado en un único repositorio de código (monorepositorio en el modelo 1:N) estructurado de tal forma que todas las aplicaciones están distribuidas en diferentes carpetas organizadas siguiendo diversos criterios, habitualmente propios y específicos de ese cliente/proyecto.
Tanto el modelo repo-app 1:1 como el modelo 1:N presentan pros y cons y existe una motivación detrás de cada una de estas opciones: una gestión del ciclo de vida de CI/CD en el que los pipelines deben respetar las interdependencias existentes entre las diferentes aplicaciones del monorepositorio en cuestión es una razón de peso para considerar dicho modelo como el adecuado. Y todo esto nos plantea retos en cuanto a la generación de una definición de integración continua que se adapte a esta casuística descrita en la que múltiples aplicaciones comparten un único repositorio y cuyo ciclo de vida debe orquestarse atendiendo a la interdependencia entre ellas.