¿Mi pipeline de CI/CD es un Frankenstein? Revisión de arquitectura para deploys multi-entorno

OpenSource

Hace unos meses monté un pipeline de CI/CD para un proyecto con microservicios. Uso GitHub Actions para build, test y deploy a staging, y luego un job manual para producción. El problema: cada microservicio tiene su propio workflow, y ahora tengo 15 archivos YAML casi idénticos. Cuando cambio algo (ej. versión de Node), toco 15 archivos. Además, para el deploy a producción, uso un script bash que hace ssh a un servidor y ejecuta docker-compose. Siento que esto no escala y que es frágil. ¿Qué harían ustedes? ¿Moverme a ArgoCD? ¿Usar matrices en GitHub Actions? ¿O estoy sobrecomplicando y esto es normal?

Quilting

Lo que describes es un clásico: duplicación de lógica. Antes de saltar a herramientas más complejas, yo consolidaría los workflows en uno solo usando una matriz (matrix) en GitHub Actions. Defines los servicios como una lista y entonces un solo workflow itera sobre ellos. Menos archivos, y los cambios se hacen en un solo lugar. Algo como:

strategy:
  matrix:
    service: [auth, api, frontend]

Para el deploy, te recomendaría que no uses ssh directo; usa un artefacto como una imagen Docker y un orquestador. No necesitas ArgoCD si no tienes cluster Kubernetes. Pero si estás en Kubernetes, ArgoCD es una gran opción.

VR

Estoy de acuerdo con lo de la matriz, pero cuidado: si cada microservicio tiene dependencias o pasos distintos, la matriz se vuelve un infierno de condicionales. Yo prefiero un enfoque de workflow reutilizable (reusable workflow). Creas un workflow base con inputs y reutilizas ese desde cada servicio. Sí, sigues teniendo 15 archivos, pero cada uno es de 10 líneas y el core está en un solo lugar. Es más limpio para proyectos heterogéneos.

Philosopher

Para el deploy, el patrón de GitOps con ArgoCD es la mejor inversión a largo plazo. No solo por el pipeline, sino porque te da trazabilidad y rollback automático. Si ya estás usando Docker, puedes levantar un minikube o un cluster pequeño. Sí, hay curva de aprendizaje, pero tu yo del futuro te lo agradecerá. Y si te preocupa el acoplamiento, ArgoCD se encarga de sincronizar el estado del cluster con tu repo de Git.

VR

No estoy de acuerdo con ir directo a ArgoCD si no tienes experiencia con Kubernetes. Eso es añadir una complejidad enorme a un problema que quizás se resuelve con un simple script de deploy centralizado. Yo haría lo siguiente: un solo script de deploy (por ejemplo en Python o bash) que tome como parámetro el servicio y el entorno. Ese script lo llamas desde tu workflow. Así tienes una pieza única de lógica de deploy, sin 15 copias. Y para entornos, usa variables de entorno y archivos de config separados.

Calligraphy

También podrías considerar GitHub Environments para proteger producción con aprobaciones manuales y secrets separados. Eso ya lo tienes, pero asegúrate de que el job de producción no dependa del de staging (debe ser independiente para que puedas deployar solo a prod si quieres). Y otra cosa: ¿estás usando caché para las dependencias? Si no, estarás perdiendo tiempo de build. Eso es más importante que la arquitectura del pipeline.

OpenSource

Gracias por todas las respuestas. Me inclino por la idea de workflow reutilizable + un script de deploy centralizado. La matriz me da miedo porque algunos servicios tienen tests de integración que necesitan más recursos. Y sobre ArgoCD, lo estoy evaluando, pero primero quiero domar el pipeline actual. Me gustó lo de los entornos de GitHub, ya lo tengo. Ahora, ¿alguien ha pasado por una migración de este tipo y ha visto un antes/después en el tiempo de mantenimiento? Me preocupa que al principio cueste más.

SpaceFan

Yo migré de 20 workflows a 2 reutilizables hace un año. El tiempo de mantenimiento bajó drásticamente. El primer mes fue un dolor porque tuve que aprender la sintaxis de workflow_call y ajustar los secrets. Pero después, cualquier cambio de versión de Node o de paso de build es un solo commit. Te recomiendo que hagas una prueba con un servicio piloto, y luego migres los demás. Y no te olvides de versionar los workflows reutilizables con tags o SHAs, para que no se rompa todo a la vez.

OpenSource

¡Perfecto! Eso me da confianza. Voy a probar con el servicio de autenticación primero. También probaré lo del script centralizado en Python para reemplazar el ssh. Si alguien tiene un ejemplo de cómo manejar los secrets en el workflow reutilizable, se lo agradecería. Voy a dejar el hilo abierto por si acaso. ¡Gracias a todos!

Linux

Importante: con workflow_call los secrets se pasan explícitamente con secrets: inherit o mapeándolos. Si usas entornos de GitHub, cada entorno tiene sus propios secrets y puedes referenciarlos en el workflow reutilizable usando environment: ${{ inputs.environment }}. Así evitas tenerlos en el nivel raíz. Para el script centralizado, si vas a usar Python, te recomiendo fabric o paramiko para el SSH, y manejar los secrets con variables de entorno que el workflow inyecta. Un antes/después claro: pasé de 15 workflows a 2, y el tiempo de actualización de dependencias pasó de horas a minutos. Sí, el primer mes es más trabajo, pero el ROI llega rápido. Eso sí, versiona los workflows con tags y usa ref en el uses, no te quieras comer un cambio rompedor en producción.