Ejercicios resueltos de DevOps y CI/CD

Question 1

El pipeline corre en cada push: instalar dependencias 4 min, compilar 3 min, pruebas unitarias 6 min, pruebas de integración 14 min y despliegue al ambiente de pruebas 2 min. El equipo hace 20 push al día y se queja de la espera. Propón mejoras y calcula el ahorro.

Accepted Answer

Primero se mide, no se supone: 4 + 3 + 6 + 14 + 2 = 29 minutos de punta a punta. Las pruebas de integración solas valen 14 de esos 29, casi la mitad. Mejora 1, la más barata porque no obliga a tocar una sola prueba: guardar en caché las dependencias, con la llave calculada sobre el archivo de bloqueo. Solo se reinstala cuando ese archivo cambia, y en los demás push los 4 minutos bajan a unos 30 segundos. Mejora 2: las pruebas unitarias y las de integración no dependen unas de otras, así que corren en paralelo. La etapa deja de costar 6 + 14 = 20 minutos y pasa a costar lo que tarde la más lenta: 14 minutos. Mejora 3: el despliegue al ambiente de pruebas no tiene por qué correr en cada push de cada rama. Se deja solo para la rama principal y sale de la ruta de espera del desarrollador. Nuevo tiempo para un push de rama: 0,5 + 3 + 14 = 17,5 minutos. Ahorro por push: 29 − 17,5 = 11,5 minutos. Por día: 11,5 × 20 = 230 minutos, o sea unas 3 horas y 50 minutos de espera que el equipo deja de pagar. Lo que queda pendiente es el verdadero cuello de botella: 14 minutos de pruebas de integración. El siguiente paso es partirlas en grupos que corran en paralelo en varias máquinas. Respuesta: De 29 a 17,5 minutos con caché de dependencias, pruebas en paralelo y despliegue solo en la rama principal: unos 230 minutos menos de espera al día.

Question 2

Un equipo despliega a producción volviendo a compilar desde la rama principal. La versión pasó todas las pruebas en el ambiente de pruebas y en producción falló al arrancar. Nadie tocó el código en el medio. ¿Qué principio de entrega continua se está rompiendo?

Accepted Answer

Se rompe «construir una vez, desplegar muchas». Al recompilar para producción se produce un artefacto DISTINTO del que se probó, aunque el commit sea el mismo. Las tres formas típicas en que el artefacto cambia sin que nadie toque el repositorio: una dependencia declarada con rango (el acento circunflejo en package.json) trae una versión menor nueva; la imagen base etiquetada como latest cambió en el registro; y entre un despliegue y otro entraron commits a la rama principal. La conclusión es dura pero es la que importa: lo que se probó no es lo que se desplegó, así que el ambiente de pruebas no dio ninguna garantía sobre producción. La corrección: compilar una sola vez, etiquetar el artefacto con el identificador del commit, guardarlo en un registro y PROMOVER ese mismo artefacto, byte por byte, a pruebas, a preproducción y a producción. Lo único que puede cambiar entre ambientes es la configuración, y se inyecta por variables de entorno o por un gestor de secretos al momento de arrancar, nunca se compila adentro del artefacto. El beneficio adicional: con el artefacto guardado y etiquetado, volver atrás es desplegar la etiqueta anterior en segundos, en vez de recompilar bajo presión mientras el sistema está caído. Respuesta: Se viola «construir una vez, desplegar muchas». Se compila un solo artefacto etiquetado con el commit, se guarda en el registro y se promueve el mismo a todos los ambientes; entre ambientes solo cambia la configuración inyectada.

DevOps y CI/CD