El despliegue continuo con GitHub Actions te permite tomar una imagen de Docker ya construida y publicarla automáticamente en servicios cloud como AWS App Runner, GCP Cloud Run o Azure Container Instances. Esta guía te muestra cómo estructurar el workflow file y reutilizar lo que ya hiciste en integración continua.

¿Qué hace un flujo de despliegue continuo (CD) con GitHub Actions?

Un flujo CD toma la imagen que subiste a un registry y la despliega en un servicio cloud para que tus usuarios accedan a ella. La idea es encadenar este paso después del flujo de CI, donde ya testeaste y compilaste la imagen.

En el repositorio de ejemplo, el archivo se llama cd.yml y tiene como name y run-name el valor flujo CD para identificarlo fácil en la pestaña Actions. Se ejecuta solo de forma manual mediante workflow_dispatch, que recibe un input con el proveedor cloud elegido: AWS, GCP o Azure.

¿Qué es workflow_dispatch? Es un trigger que permite lanzar un workflow manualmente desde la interfaz de GitHub, opcionalmente recibiendo inputs definidos por ti.

Cada proveedor tiene su propio job con un condicional if que verifica el input antes de ejecutar los pasos. Así eliges en qué nube desplegar sin duplicar workflows.

¿Cómo desplegar una imagen Docker en AWS App Runner?

El job de AWS corre en un runner de Ubuntu y arranca configurando credenciales con la action oficial Configure AWS Credentials, que recibe access-key-id, secret-access-key y la región de despliegue.

El segundo paso crea un archivo apprunner.json con la configuración que App Runner necesita para actualizar el servicio. Dentro del archivo se incluyen:

• El service ARN, que es el identificador del proyecto en AWS y se guarda como variable de entorno del repositorio.
• El source configuration con la URL de la imagen en ECR, el alias del registry, el nombre del repositorio y el tag latest.
• La indicación de que el repositorio es público, porque AWS ofrece una capa gratuita generosa para repositorios públicos en ECR.

El último paso ejecuta en la terminal el comando aws apprunner update-service pasándole ese archivo. App Runner detecta el cambio de imagen y actualiza la versión desplegada automáticamente.

¿Cómo desplegar en GCP Cloud Run desde GitHub Actions?

El job de GCP también corre en Ubuntu y se activa solo si elegiste GCP en el workflow_dispatch. Define variables de entorno con el project_id, el service_name y la región, igual que en el paso de CI donde compilaste la imagen.

El primer paso usa la action auth de google-github-actions para autenticarte y guardar las credenciales en el runner. Recibe el project_id y un secret con la service account key que sacas desde la consola de GCP. El parámetro token_format le indica que genere un access token.

El segundo paso autentica al artifact registry de GCP, que es privado, así que necesitas credenciales para descargar imágenes. Usas como username oauth2accesstoken y como password el access token del paso anterior, accediendo a sus outputs mediante el ID del step.

¿Qué es Cloud Run? Es el servicio serverless de GCP equivalente a AWS App Runner. Ejecuta contenedores bajo demanda y escala automáticamente según el tráfico.

El paso final usa la action oficial deploy-cloudrun de google-github-actions. Recibe el path completo de la imagen (region, registry, project_id, repositorio, nombre y tag latest), la región de despliegue y el service_name. Cloud Run publica la nueva versión y queda disponible para tus usuarios.

¿Cómo desplegar en Azure Container Instances?

El job de Azure sigue el mismo patrón: corre en Ubuntu y tiene su condicional para activarse solo cuando lo eliges. El primer paso autentica con credenciales de Azure y las guarda en el runner.

El paso clave usa la action aci-deploy, que crea o actualiza el Azure Container Instance. Recibe estos parámetros, todos guardados como variables de entorno del repositorio:

• resource-group: el grupo de recursos donde vive el container instance, sacado de la consola de Azure.
• name: el nombre con que se identifica el container instance dentro de Azure.
• dns-name-label: la etiqueta DNS para acceder públicamente al contenedor.
• image: la ruta de la imagen en el Azure Container Registry, la misma del paso de build.
• registry-username y registry-password: para autenticarse contra el ACR.
• location: la región donde se despliega.

Con esto Azure levanta el contenedor y queda accesible mediante la URL configurada.

¿Por qué reutilizar actions del marketplace en tus workflows?

La fuerza de GitHub Actions está en el marketplace, que tiene más de 17 000 actions creadas entre empresas oficiales y comunidad. En este flujo CD reutilizaste actions oficiales de AWS, Google y Azure sin escribir lógica desde cero.

Lo importante no es dominar los tres proveedores cloud, sino entender la sintaxis de los jobs, los steps, los condicionales if y cómo encadenar el output de un workflow de CI con uno de CD. Con esa base puedes adaptar el flujo a cualquier servicio donde decidas que tu proyecto debe vivir.

¿Ya probaste replicar esto en tu proyecto personal? Cuéntame en los comentarios cuál proveedor elegiste y qué retos encontraste al configurar tus credenciales.