Caso práctico
De un git push a production — sin miedo
Una app real ejecutándose en Managed Containers, conectada a un repositorio de GitHub. Cada push a main compila y despliega automáticamente — pero a una copia Staging, nunca directo a production. Cuando se ve bien, un clic pone ese build exacto en vivo. Sin 504 durante los builds, sin deploys de "espero que funcione". Consulte las guías de referencia Flujo de despliegue y Deploy from Git para el cómo hacerlo.
1. Conecte el repositorio una vez — el flujo aparece solo
La app de ejemplo es una pequeña aplicación web de árbol genealógico (un servicio Node detrás de un contenedor). Conectar su repositorio de GitHub es toda la configuración necesaria:
- En Platforms → Container Apps, conecte GitHub y elija el repositorio y el branch (
main). - Eso convierte la app en un Flujo de despliegue: un entorno Staging (una copia de prueba en su propia URL
ca-*.cdn.com.tr) y Production, con un botón Promote entre ambos. - A partir de ahora, cada push se auto-despliega a Staging — nunca toca production al hacer push de código.
2. Cada push llega a Staging — production sigue sirviendo
Esta es la misma app en ambos entornos en el mismo momento. Observe la marca de build en el pie de página: Staging ya tiene el build más nuevo del último push, mientras que Production todavía sirve el anterior. Nada se recompiló en la app de production, así que hubo cero tiempo de inactividad y ningún 504 mientras el nuevo build se compilaba.
- Staging compiló y desplegó automáticamente el último commit — accesible en su propia URL de prueba.
- Production permanece intacta: mismo build en ejecución, mismo dominio en vivo, sin interrupciones.
- Prueba el nuevo build en un entorno real y aislado antes de que un solo usuario de production lo vea.
3. Verifique en la URL real de Staging
Staging es una copia real y en ejecución de la app en su propio subdominio — misma imagen, mismos complementos— así que puede recorrer el cambio real, no una simulación. Solo avanza cuando todo está correcto.
- Abra la URL de prueba de Staging desde la tarjeta del flujo y pruebe el cambio de extremo a extremo.
- ¿Rompió algo? Simplemente haga push de una corrección — Staging se redespliega, Production sigue a salvo.
4. Promote: un clic, cero recompilación
Promote no compila nada. Cambia el origen del dominio de production hacia el build de Staging ya en ejecución — un cambio instantáneo y atómico. El build que probó es, byte por byte, el build que se pone en vivo.
- Haga clic en Promote en la tarjeta del flujo — production ahora sirve exactamente el build que verificó en Staging.
- Al ser un cambio de origen de dominio (no una recompilación), la transición es instantánea y sin tiempo de inactividad.
- El rollback es lo mismo, a la inversa: un clic devuelve production al build anterior (con una instantánea de la base de datos cuando la app tiene una).
El mismo flujo desde la terminal (cdnctl)
Todo lo anterior es programable — útil para CI. El panel y cdnctl usan los mismos endpoints:
# Connect once in the panel, then every push to main auto-deploys to Staging.
# Verify Staging on its test URL, then promote the tested build to production:
cdnctl container apps status --account <uuid> --app <staging_app_uuid>
cdnctl container apps promote --account <uuid> --app <staging_app_uuid>
# Roll back to the previous production build if needed (instant, no rebuild):
cdnctl container apps rollback-promotion --account <uuid> --app <prod_app_uuid>Por qué esto es seguro por diseño
- Hacer push de código nunca puede romper production — el auto-deploy solo apunta a Staging.
- Lo que promueve es exactamente lo que probó (no hay recompilación entre la prueba y lo publicado).
- La transición y el rollback son cambios instantáneos de origen de dominio, no redespliegues lentos.
- Los builds ocurren aparte, así que el sitio en vivo nunca devuelve 504 mientras se compila.
Guías de referencia: Flujo de despliegue · Deploy from Git · Entornos Blue/green.