Concepto clave

Los despliegues automatizados a entornos cloud son el proceso de implementar aplicaciones en infraestructura remota sin intervención manual, usando GitHub Actions como orquestador. Imagina que eres un piloto de drones: defines la ruta (tu workflow), configuras los puntos de aterrizaje (entornos como staging o producción), y el dron ejecuta el vuelo automáticamente cada vez que hay un cambio en el código. Esto elimina errores humanos y acelera la entrega de valor.

En el contexto de CI/CD, esto significa que tras pasar los tests, tu aplicación se despliega directamente a servicios como AWS, Azure, o Google Cloud. La clave está en la integración segura: GitHub Actions usa secrets para almacenar credenciales de cloud (como claves de API) y los inyecta en el runtime, manteniendo tu infraestructura protegida. Es como tener un mensajero confiable que lleva paquetes sellados a destinos específicos, sin que nadie más pueda abrirlos.

Cómo funciona en la práctica

Veamos un ejemplo paso a paso para desplegar una app Node.js a AWS Elastic Beanstalk:

Configuración inicial: Crea un repositorio en GitHub con tu código y un archivo appspec.yml para AWS.
Secrets en GitHub: Ve a Settings → Secrets and variables → Actions, y añade AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.
Workflow de GitHub Actions: Crea un archivo .github/workflows/deploy.yml que defina el job de despliegue.
Ejecución automática: Al hacer push a la rama main, el workflow corre: build → test → deploy usando los secrets.
Verificación: Revisa los logs en GitHub Actions y accede a tu app en la URL de AWS.

Este flujo asegura que cada cambio validado llegue a producción en minutos, no en horas.

Codigo en accion

Antes: Un despliegue manual con scripts locales propenso a errores.

# deploy-manual.sh (ejemplo viejo)
echo "Building..."
npm run build
echo "Uploading to AWS..."
aws s3 sync ./dist s3://my-bucket --profile my-profile
# Problema: depende de tu máquina y credenciales locales

Despues: Un workflow de GitHub Actions automatizado y seguro.

# .github/workflows/deploy.yml
name: Deploy to AWS
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Deploy to AWS Elastic Beanstalk
        uses: einaregilsson/beanstalk-deploy@v21
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: my-app
          environment_name: my-app-prod
          region: us-east-1
          version_label: ${{ github.sha }}
          deployment_package: ./dist.zip

Errores comunes

Exponer secrets en logs: Nunca imprimas ${{ secrets.XXX }} con echo. GitHub los ofusca, pero errores en scripts pueden filtrarlos. Usa run: echo "Deploying..." sin detalles sensibles.
Falta de rollback automático: Si el despliegue falla, tu app puede quedar rota. Implementa health checks en el workflow y usa estrategias como blue-green en cloud para revertir.
Despliegues a ramas incorrectas: Desplegar desde feature branches a producción causa inestabilidad. Configura on: push: branches: [main] y usa entornos separados para staging.
Ignorar costos de cloud: Los workflows que corren frecuentemente pueden generar gastos altos. Optimiza con caching de dependencias y triggers precisos (ej., solo en tags).
Permisos insuficientes en secrets: Si el job falla por acceso denegado, verifica que los secrets tengan los scopes correctos (ej., permisos de escritura en AWS).

Checklist de dominio

Configuré secrets en GitHub para credenciales de cloud (ej., AWS, Azure).
Mi workflow incluye steps para build, test y deploy en un solo job o jobs separados.
Uso entornos en GitHub Actions para gestionar staging y producción con approvals.
Implementé health checks post-deploy para verificar que la app este funcionando.
Probé rollback manual o automático en caso de fallo en producción.
Optimicé el tiempo de ejecución con caching de dependencias (ej., actions/cache).
Documenté el proceso de despliegue en el README para el equipo.

Configura un despliegue automatizado a Google Cloud Run

En este ejercicio, vas a crear un workflow de GitHub Actions que despliegue una app contenerizada a Google Cloud Run. Sigue estos pasos:

Prepara tu repositorio: Crea un repositorio en GitHub con un Dockerfile simple para una app web (puedes usar un ejemplo de Node.js o Python). Asegurate de que el Dockerfile construya correctamente localmente.
Configura Google Cloud: En Google Cloud Console, crea un proyecto, habilita Cloud Run y Container Registry. Genera una clave de servicio JSON con permisos de Cloud Run Admin y Container Registry Writer.
Añade secrets a GitHub: En tu repositorio, ve a Settings → Secrets and variables → Actions. Crea un secret llamado GCP_SA_KEY y pega el contenido completo de la clave de servicio JSON.
Crea el workflow: En .github/workflows/deploy.yml, define un job que:
- Se ejecute en push a main.
- Haga checkout del código.
- Construya la imagen Docker y la suba a Google Container Registry usando el secret.
- Despliegue a Cloud Run con un nombre de servicio y región.
Prueba el despliegue: Haz un push a main y verifica en GitHub Actions que el job termine exitosamente. Accede a la URL generada por Cloud Run para ver tu app.

Entrega: Comparte el enlace a tu repositorio y una captura del workflow exitoso.

Pistas

Usa la accion oficial google-github-actions/deploy-cloudrun para simplificar el despliegue.
Asegurate de que el Dockerfile exponga el puerto correcto (ej., 8080 para Cloud Run).
Verifica que el secret GCP_SA_KEY este en formato JSON valido, sin saltos de linea extra.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Quiz: Despliegues Automatizados

Quiz Interactivo