Un lugar seguro para probar cada funcionalidad
Un piloto de dos repositorios para preview environments aislados, image promotion probada y cleanup automatizado.
Piloto de dos repositorios: promueve la imagen probada y luego elimina los recursos de preview cuando se cierra el PR.
Contribución de un vistazo
- Mi responsabilidad
- Flujos de trabajo de CI, ArgoCD ApplicationSets, configuración de Helm y ciclo de vida de los previews.
- Alcance
- Un piloto de dos repositorios en Go/Node; una adopción más amplia en la empresa queda fuera del alcance entregado.
- Colaboración y límites
- Construí la integración de plataforma que conecta repositorios relacionados; el caso no afirma una adopción por parte de desarrolladores en toda la organización.
- Resultado
- 34 verificaciones antes de los builds, promotion verificada de la misma imagen y cleanup cuando se cierra el pull request.
El problema
QA dependía de entornos compartidos de desarrollo y staging. Muchas veces las funcionalidades solo se encontraban entre sí después del merge, lo que dificultaba probar un cambio de backend/frontend de forma aislada y coordinar el trabajo entre equipos.
Mi contribución
Construí un piloto de preview environments en un backend de Go y un frontend de Node. El trabajo abarcó flujos de trabajo de CI, ArgoCD ApplicationSets, configuración de Helm, ciclo de vida de namespaces, TLS, la integración entre las dos aplicaciones y la ruta de cleanup cuando se cerraba un pull request.
Las decisiones
Una convención compartida de nombres de rama permite que los repositorios relacionados lleguen al mismo namespace de preview. Eso permite que un frontend alcance su backend correspondiente a través de un servicio interno, sin tratar cada repositorio como una demostración aislada.
Separé los flujos de trabajo de build/test de los flujos de trabajo de deploy. La promotion a producción y a sandbox reutilizó la imagen de staging probada en lugar de reconstruirla. El digest de la imagen se verificaba entre entornos, de modo que la promotion significaba mover el binario probado en lugar de reproducir un build y asumir equivalencia.
Los previews usaban una configuración de runtime deliberadamente más pequeña que los entornos persistentes. La creación era solo la mitad de la funcionalidad: cerrar o hacer merge del pull request también debía eliminar la aplicación, el namespace y las imágenes de preview.
Validación
El piloto ejecutó 34 verificaciones automatizadas antes de los builds: 16 para Go y 18 para Node. El cleanup se ejercitó de extremo a extremo, y la salud y la sincronización de la aplicación se verificaron en ArgoCD. Pruebas separadas verificaron la image promotion sin reconstruir.
Resultados y medición
El registro de finalización documenta ambos repositorios del piloto recorriendo el flujo de preview, ocho aplicaciones de ArgoCD sincronizadas y sanas, y digests de imagen idénticos durante la promotion. Una ruta observada de push-to-deploy tardó aproximadamente 2 minutos 14 segundos; es una observación del piloto, no una garantía de tiempo de deploy para toda la flota.
El alcance fueron dos repositorios piloto. La adopción más amplia, el tiempo total ahorrado por los desarrolladores y los cambios en la tasa de escape de defectos no se midieron en este registro. Un piloto completado no establece una adopción en toda la empresa ni un resultado de endurecimiento para producción.
Lo que aprendí
Una funcionalidad de plataforma se vuelve útil cuando se conecta con el flujo de trabajo del equipo. Los namespaces de preview compartidos, una promotion confiable y un cleanup explícito importaron tanto como crear el deploy inicial.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Un staging compartido usa menos entornos; los previews aislados reducen las colisiones entre funcionalidades, pero requieren convenciones de ciclo de vida y entre repositorios.
Contrapartida
Un entorno fácil de crear aún necesita una promotion segura y un cleanup confiable para evitar recursos obsoletos y gasto.
Lo que mejoraría a continuación
Próxima mejora: medir la adopción, el tiempo de preparación de los previews y el costo de recursos huérfanos antes de expandir más allá del piloto.