Publicar una rama, abrir un pull request y ver cómo todo se despliega solo. Ese es el momento donde convergen las siete tecnologías del curso: GitHub Actions, Azure Container Apps, pruebas automatizadas, OpenTelemetry y más. Si estás aprendiendo CI/CD con GitHub y Azure, aquí ves el flujo completo en acción.

Qué pasa cuando publicas una rama y abres un pull request

Todo arranca con un gesto pequeño: publicar la rama admin-ES3 desde tu editor hacia GitHub. A partir de ahí, la plataforma te sugiere comparar cambios y abrir el pull request que dispara la cadena de automatización.

Dentro del pull request le pedimos a Copilot un resumen de los cambios, nos asignamos como autores y agregamos a Óscar como revisor. También vinculamos el issue número tres con la palabra clave close #3, para que GitHub cierre la tarea automáticamente cuando se fusione la rama.

¿Qué hace close #3 en un pull request? Cierra automáticamente el issue número tres cuando el pull request se fusiona con la rama principal. Es la forma estándar de enlazar trabajo y tareas en GitHub.

Cómo se ejecutan las pruebas automatizadas antes de fusionar

Apenas se abre el pull request, GitHub Actions ejecuta la batería de pruebas. No es opcional: es la barrera que protege a main de cambios rotos.

El flujo tiene dos pasos claros:

• Primero, las pruebas automatizadas validan que el nuevo método de contactos funciona y no rompe lo existente.
• Segundo, Óscar revisa el código y da su aprobación manual al pull request.

En este caso, las pruebas pasaron de una a dos, porque sumamos una nueva al cubrir el método recién creado. Cuando ambas quedan en verde y la revisión humana aprueba, la rama se puede fusionar con la rama por defecto sin sobresaltos.

Cómo funciona el despliegue automatizado en Azure Container Apps

Una vez fusionada la rama, GitHub Actions vuelve a entrar en escena con el workflow de despliegue. El paso que más nos importa se llama Deploy Container App, y es el que empuja la nueva versión de la API hacia Azure.

Desde el portal de Azure (algo que como desarrollador rara vez necesitas abrir) podemos confirmar que contactos-api está corriendo, con sus revisiones y réplicas en estado saludable. Un Ctrl + F5 en el workbook y ahí aparece el nuevo método obtener contactos, listo para responder consultas.

¿Qué es Azure Container Apps? Es un servicio de Azure que ejecuta contenedores sin que tengas que gestionar la infraestructura. Tu API vive ahí como una aplicación con revisiones y réplicas administradas.

¿Por qué usar OpenTelemetry en este flujo? Porque te permite validar que las consultas al nuevo método se reflejan correctamente en el workbook de observabilidad, confirmando que el despliegue funciona de extremo a extremo.

Qué piezas hacen posible este flujo de trabajo

Lo interesante es que cada componente del curso tiene un rol específico en este momento final. No sobra ninguno.

• GitHub y pull requests: orquestan el control de cambios, la revisión humana y el cierre de issues con close #3.
• Copilot: genera el resumen del pull request para que el revisor entienda el contexto en segundos.
• GitHub Actions: ejecuta pruebas en cada pull request y dispara el despliegue tras la fusión con main.
• Azure Container Apps: aloja la API contactos-api con revisiones y réplicas gestionadas.
• OpenTelemetry y workbooks: validan que las consultas al nuevo método se registran y se visualizan correctamente.
• Batería de pruebas: pasa de una a dos pruebas al sumar el método de contactos, protegiendo la rama principal.

Después de la lista, vale la pena detenerse en algo: una vez configurado todo, agregar nuevos métodos a la API se vuelve trivial. Tú escribes el código, abres un pull request, y GitHub más Azure se encargan del resto.

Por qué este flujo cambia tu forma de trabajar

Llegar hasta aquí requirió configurar infraestructura, pruebas automatizadas, pull requests protegidos, despliegue continuo y observabilidad. Pero el resultado es contundente: puedes agregar métodos a tu API a diestra y siniestra sin mover un solo dedo más en infraestructura.

Ese es el verdadero valor de CI/CD bien montado. Cada nuevo commit viaja por un camino seguro, validado y trazable hasta producción. Y tú te concentras en lo que importa: escribir código que resuelva problemas.

¿Cuál parte de este flujo te gustaría implementar primero en tu propio proyecto? Cuéntalo en los comentarios.