Este va a ser un articulo corto. Y es un pequeño infierno de dependencias. Creo que ligeramente detallado en otro articulo de GitOps y Jenkins.
Se preguntaran ¿A que se refiere con autobranch?
Bien, el autobranch es una estrategia que se puede usar en flujos de compilacion, integracion y pruebas automatizadas. Es la capacidad de crear ramas y etiquetas de Git. Mediante diferentes etapas del flujo automatizad. De forma que cada ambiente, y cada etapa cree su rama puedan ser autonomas y no modifiquen el trabajo original.
¿Suena bien no? Realmente todo suena bien hasta que es implementado De forma peculiar.
En esa ocasion, durante una consultoria salvaje, se presento un escenario como el siguiente.
El repositorio tenia los siguientes commits
A -> B -> C -> D.
Cuando cualquier desarrollador iniciaba un proceso de merge a desarrollo sucedia lo siguiente. feature/e basado en D.
feature/E
A -> B -> C -> D -> feature/E
Lo cual disparaba 3 procesos y creaba 3 ramas de forma incremental.
feature/E-compiled. El nuevo commit agregaba los parametros de build
feature/E-integrated. El nuevo commit encima de compiled desplegaba en ambiente de pruebas
feature/E-tested. El nuevo commit agregaba mas archivos para las pruebas automaticas.
Y finalmente se hacia merge. Se borraba todo lo agregado en los ultimos commits , se creaba una nueva rama llamada solo ‘E’.
A -> B -> C -> D ————————————-> E
-> ft/E -> ft/E-c-> ft/E-i-> ft/E-t -> E
Es bastante funcional para las tonterias que se ven normalmente. El problema es que descargar el repositorio se volvio infinitamente pesado despues de años de trabajo.
El otro problema es que de ft/E a E no era necesario la eliminacion. Porque era volver al estado inicial.
El otro problema es que las ramas no se eliminaban. Es decir se mantenian los commits pero no se eliminaban las ramas. Lo cual causo una sobrecarga en la navegacion y en la revision de ramas, ya que tenian cientos, quiza miles y nunca las habian removido.
De igual forma que los cambios de cada desarrollador no recibian ningun tipo de Squash. A cada conjunto de commits de un developer se retornaba al menos +4 commits.
Si bien la mayoria de problemas eran de orden, es decir, tenian miles de ramas en cualquier busqueda, ningun editor soporta ello. buscar una ram era una pesadilla, navegar, o se hacia con grep, o se necesitaban los nombres exactos de las ramas, no se sabia donde navegar, no habia limpieza.
Pero el verdadero problema fue con el espacio de disco y el tamaño de repositorio.
¿Por que se preguntaran?
De mi narracion los dejare pensar un poco.
….
….
….
El problema es el primer parrafo. Ya que el pipeline estaba mal diseñado, y no tenian un correcto .gitignore.
Resulta que cada vez que se creaba una rama del CI/CD. Los binarios se adjuntaban al repositorio. Cada version de los binarios, y los resultados de las pruebas. Y aunque se eliminaban en la version mezclada a master. Sucede que git igual debe guardar estos archivos por el historico. Y el repositorio crecia y crecia.
Aparte habia un grupo de reportes que usaban los nombres de los commits para extraer los resultados de las pruebas del commit especial. (Ya que se borraba en la integracion). Lo cual basicamente en demanda causaba una descarga constante del los datos del servidor en otro, siendo un proyecto gigante consumia bastante ancho de banda en la transmision sobrecargando la red.
¿Como se soluciono?
Bien lo primero que se hizo fue partir su repositorio. Es posible en git tomar un repositorio de millones de commits, elegir una nueva base. Y partirlo. Este nuevo fragmento se reemplazo en todos sus repositorios centrales. Y nos aseguramos que no tuviera mas binarios.
Lo segundo fue mejorar el gitignore para no cargar nunca mas binarios y carpetas de build,test,deploy. A su vez como remover esos commits.
Lo tercero fue crear un mecanismo de limpieza de ramas periodicas.
Y lo cuarto fue colocar los resultados de las pruebas en un servidor de archivos no dentro del estupido código. (Esto todavia me hace tener pesadillas).
El autobranch seguiria funcionando, tiene sentido en un contexto ordenado. Pero una pequeña mala hipotesis puede mandar todo al basurero.