Desplegando microservicios con GitHub Actions

Replicar un workflow de GitHub Actions para varios microservicios parece sencillo, pero esconde detalles que marcan la diferencia entre un deploy exitoso y horas depurando errores. Si ya configuraste tu primera action para un servicio, el siguiente paso es escalar ese mismo proceso al resto de tu arquitectura sin perder la cabeza en el intento.

¿Cómo replico una GitHub Action para varios microservicios?

El punto de partida es tu repositorio con la carpeta microservices, donde cada proyecto vive en su propio directorio. La estrategia es crear una action independiente por servicio, copiando el archivo main original y ajustando solo lo necesario.

En mi caso configuré cinco actions que hacen exactamente lo mismo que la primera (la de Add Member), pero apuntan a servicios distintos. Para cada archivo yaml, como pick-age.yaml, los cambios son puntuales:

• Actualizar el nombre del workflow.
• Cambiar el nombre del servicio y de la imagen.
• Modificar la ruta de referencia al proyecto dentro del repo.
• Ajustar las variables de entorno según el servicio.

¿Qué archivos necesito modificar al copiar una GitHub Action? Solo el yaml del workflow: nombre, imagen, ruta del proyecto y variables de entorno. El resto de la lógica del pipeline permanece idéntica.

¿Cuándo elimino el puerto externo y el ingress?

No todos los microservicios necesitan exponerse al mundo. El servicio de selección de edad, por ejemplo, trabaja internamente, así que removí el puerto externo y el ingress. Esto reduce superficie de ataque y mantiene la arquitectura limpia.

Para servicios que se comunican vía mensajería, otro cambio clave: en lugar de una queue, usé un Service Bus Topic Name. Ese ajuste va dentro de las variables de entorno justo después de la ruta.

¿Por qué fallan los pipelines de CI/CD las primeras veces?

Aquí va la parte que rara vez te muestran en clase. De nueve workflows ejecutados para Get Adult, solo cuatro corrieron bien al inicio. De 59 runs totales en el proyecto, una cantidad considerable terminó en rojo.

Las causas más comunes de fallo son tan tontas como dolorosas: una coma faltante, un espacio de más, un guion que se perdió al copiar. Nada de errores conceptuales profundos, solo detalles de sintaxis en yaml.

¿Cuánto tarda en estabilizarse un workflow de GitHub Actions? Depende del servicio, pero es normal fallar cinco veces antes de obtener un run verde. La paciencia y leer bien los logs son tus mejores herramientas.

La lección práctica: cuando trabajas con GitHub Actions y pipelines de CI/CD, necesitas paciencia y saber leer los errores. Identificar dónde está la falla y cómo interpretarla es una habilidad que se entrena fallando.

¿Cómo verifico que mis microservicios funcionan en la nube?

Una vez que el workflow aparece en verde, el siguiente paso es validar el despliegue desde el portal. En el servicio Add Member revisas las revisions: si todo está escalado correctamente, vuelves a la sección overview y copias la URL pública.

El flujo de prueba es directo:

1. Copiar la URL del servicio desplegado en la nube.
2. Volver a Visual Studio y reemplazar la URL local por la nueva.
3. Ejecutar la query contra el endpoint remoto.
4. Confirmar en la base de datos que el registro existe.

La primera petición tardó alrededor de 2,500 microsegundos, pero al repetirla el tiempo bajó considerablemente. Es como si la aplicación necesitara despertar tras el despliegue inicial. Probé enviando un registro con el nombre Pepe, luego Ramiro, y ambos quedaron correctamente persistidos.

¿Cómo pruebo el endpoint Get Adult desplegado?

Para Get Adult el proceso es el mismo, pero con su propia URL pública. Vas al entorno apps, sección Get Adult, copias la URL y la pegas en Visual Studio reemplazando la versión Docker local. Seleccionas la request, envías y revisas los logs.

Si todo está bien configurado, vas a ver la respuesta del servicio igual que en tu entorno local. La diferencia es que ahora corre en infraestructura cloud, listo para escalar.

¿Qué hago si las primeras requests tardan demasiado?

Los servicios recién desplegados necesitan tiempo de propagación. No es raro que las primeras llamadas respondan lento o incluso parezcan colgadas. Dale unos segundos al servicio para que se estabilice antes de asumir que algo está roto.

Una vez calientes, los endpoints responden con la misma fluidez que en local. Tu set completo de microservicios queda desplegado en la nube gracias a GitHub Actions, replicando el comportamiento de tu entorno de desarrollo.

Ahora te toca a ti experimentar con las requests, romper cosas, leer logs y ajustar tus yaml. ¿Cuál fue el error más frustrante que encontraste al replicar tus workflows? Cuéntalo en los comentarios.