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.