Desplegar una Container App en Azure usando GitHub Actions convierte tu API en un servicio público con una URL accesible. Aquí entenderás cómo conectar tu service principal, configurar secretos y orquestar el flujo CI/CD para que tu aplicación quede lista para el mundo.

¿Cómo limpiar ramas locales antes de un nuevo despliegue?

Antes de tocar la infraestructura, conviene ordenar el repositorio local. Cuando trabajas con pull requests, GitHub elimina la rama remota, pero la copia local sigue ocupando espacio y generando ruido visual.

Desde la terminal puedes hacer este aseo rápido [00:24]:

• git branch para listar todas las ramas existentes en tu entorno local.
• git branch -d nombre-rama para borrar las ramas que ya fusionaste.
• git pull para sincronizar main con la última versión del repositorio remoto.

¿Por qué eliminar ramas locales? Mantienen tu repositorio limpio, evitan confusiones al crear nuevas ramas y liberan espacio en disco. Es una práctica de higiene que pocos hacen, pero ayuda mucho.

¿Cómo construir el JSON de Azure credentials para GitHub?

El puente entre GitHub Actions y Azure es un secreto llamado AZURE_CREDENTIALS. Ese secreto es un JSON que mezcla la salida del service principal con el subscriptionId de tu cuenta.

Los campos que necesitas estructurar son [01:30]:

• clientId: corresponde al appId del service principal.
• clientSecret: corresponde al password generado.
• subscriptionId: el mismo que usaste al crear el RBAC.
• tenantId: el tenant que devolvió Azure.

Una vez armado el JSON completo, lo guardas como secret en GitHub con el nombre AZURE_CREDENTIALS, incluyendo las llaves {}. Si omites una llave o una coma, la action fallará al intentar el login.

¿Qué configurar en el workflow de GitHub Actions?

El archivo YAML del workflow agrega varios elementos nuevos respecto a la versión anterior. Lo encuentras en la ruta .github/workflows/api-contactos-cicd-container-deployment.yaml [02:53].

Variables de ambiente necesarias

Dentro del bloque env se definen tres datos clave:

• IMAGE_BASE_NAME: nombre base de la imagen Docker que publicarás.
• RESOURCE_GROUP: el grupo de recursos creado previamente en Azure.
• DEVOPS_ENV: el nombre del Container Apps Environment donde se desplegará la app.

También se confirma el working-directory apuntando a src/contactosapi, que es donde vive el código de la API [04:13].

Pasos del pipeline

El flujo agrega un login y un comando final que despliega la container app [05:00]:

• Login a la CLI de Azure usando AZURE_CREDENTIALS.
• Build y push de la imagen Docker hacia Docker Hub.
• Ejecución de az containerapp up con los parámetros --environment, --resource-group, --image, puerto expuesto 8080 e --ingress external.

¿Qué hace el comando az containerapp up? Crea una container app si no existe, o la actualiza reemplazando la versión anterior. Es idempotente, así que puedes correrlo en cada despliegue sin miedo.

¿Cómo validar el despliegue y acceder a la API pública?

El flujo de trabajo se cierra con un pull request hacia main. Antes de fusionar, GitHub ejecuta los checks definidos para validar las pruebas de la API [06:50].

Una observación honesta del instructor: falta un check para validar la infraestructura de Terraform, algo que sería un excelente hábito de equipo y que aún no se aplica de forma sistemática.

Una vez aprobado por el reviewer asignado (en este caso Óscar), se fusiona el PR y se elimina la rama. Ambas GitHub Actions arrancan: la de infraestructura no genera cambios y la de CI/CD ejecuta el despliegue completo.

Dónde encontrar la URL de tu API

Cuando todos los pasos terminan en verde, el job deploy container app muestra un mensaje con el enlace público. Para ver la documentación interactiva debes agregar la ruta correcta [08:35]:

• Copia la URL que aparece en el log del paso final.
• Añade al final /swagger/index.html.
• Abre el enlace y verás tu API expuesta al público.

¿Qué es Swagger en una API? Es una interfaz que documenta y permite probar los endpoints de tu API directamente desde el navegador, sin escribir código adicional.

¿Qué hacer cuando algo falla en GitHub Actions?

El mensaje aquí es de paciencia. Aprender GitHub Actions implica tropezar con detalles pequeños: llaves omitidas en el JSON de credenciales, comas mal puestas, espacios incorrectos en YAML o comillas que rompen el parser.

No porque la clase se vea fluida significa que el camino sea inmediato. Practica con calma cada bloque del YAML, revisa los logs paso a paso y ajusta hasta que el pipeline corra limpio.

Con esto cierras el ciclo: tienes infraestructura desplegada con Terraform, una API contenedorizada y un flujo CI/CD automatizado que entrega tu aplicación al público en cada merge a main. ¿Qué parte del pipeline te pareció más retadora? Cuéntalo en los comentarios.