Flujo de despliegue: push → Staging, Promote → Production

El flujo de un vistazo

git push ──▶ [ STAGING ]  ──  Promote ──▶ [ PRODUCTION ]
              se redespliega en       manual: pone en vivo
              cada push               el build probado

• Staging es una copia real y separada de su app con su propia URL de prueba <uid>.cdn.com.tr — servida a través del edge de la CDN exactamente igual que production.
• Production sigue sirviendo la versión anterior sin tocar mientras Staging compila y despliega. Solo cambia cuando usted hace Promote.
• Roll back está siempre disponible después de un Promote — se restauran el tráfico/imagen y la instantánea de la base de datos previa al promote.

1 · Conecte su repositorio (una vez)

En Platforms → Container Apps → App creation → Deploy from Git, conecte GitHub (recomendado — GitHub App con un clic, sin tokens que gestionar) o use una URL de repositorio + token de acceso, elija el repositorio y el branch, marque “Keep connected — auto-deploy on every push to this branch” y luego Build & deploy. Detalles completos: la guía Deploy from Git.

2 · Active Staging

En la tarjeta del flujo, haga clic en Enable staging. Esto crea una copia de prueba de cada una de las apps del repositorio y apunta el auto-deploy hacia ella — a partir de ese momento, los push despliegan Staging, nunca Production.

• La copia de prueba obtiene automáticamente su propia URL de prueba pública (<uid>.cdn.com.tr). Si una copia creada antes todavía no tiene URL, la tarjeta muestra un botón Get test URL.
• Data sharing (bajo “Data sharing options”, por defecto shared): shared — Staging usa la misma base de datos/Redis/almacenamiento que production (mejor para cambios de código/UI); cloned — Staging obtiene su propio MySQL con una copia de los datos (seguro para cambios de esquema); isolated — un inicio limpio.
• La primera apertura de una URL de prueba recién creada puede devolver 502 brevemente mientras el edge/DNS se activan (~un minuto) — es normal y ocurre una sola vez.

3 · Push — Staging se despliega solo

• Cada push al branch conectado compila la imagen y la despliega en Staging. La tarjeta muestra el último push (commit + hora) y el estado de Staging en vivo.
• Abra la Test URL y verifique el nuevo build — production sigue sirviendo la versión anterior, completamente sin afectar.
• Mientras Staging se está desplegando, su estado muestra deploying; Promote permanece deshabilitado hasta que la copia esté en ejecución.

4 · Promote — ponga en vivo la versión probada

Haga clic en Promote. Production comienza a servir la versión probada de inmediato — sin build y sin tiempo de inactividad. Primero se toma una instantánea automática de la base de datos, de modo que un rollback también pueda revertir los cambios de datos. Por debajo, se usa uno de dos mecanismos:

• Su propio dominio vinculado → un cambio instantáneo de origen en el edge de la CDN: el dominio de production se vincula primero a la app de staging, luego se libera de la anterior — un movimiento puro de tráfico, segundos, sin reinicio.
• Production en su subdominio <uid>.cdn.com.tr → la imagen ya compilada y ya probada se despliega en la app de production con una actualización progresiva sin brechas (el pod anterior sigue sirviendo hasta que el nuevo esté listo). Las URLs permanecen estables: la URL de prueba siempre es Staging, la URL en vivo siempre es Production.

Promote mueve el build, no la configuración: las variables de entorno y los secrets definidos en Staging permanecen en Staging. Cambie la configuración de production en la app de production.

5 · Roll back (si lo necesita)

• Después de un Promote, aparece un botón Roll back del lado de Production. Un clic restaura la versión anterior — el cambio de dominio se revierte (o se redespliega la imagen anterior) y se restaura la instantánea de la base de datos previa al promote.
• El rollback es la misma operación instantánea y sin recompilación que Promote.

Bueno saberlo

• Desactivar el flujo: “Disable staging” en la tarjeta hace que los push vuelvan a desplegar production directamente (el comportamiento anterior — puede causar tiempo de inactividad durante los deploys). La copia de prueba se conserva.
• Servicios nuevos: el auto-deploy actualiza los servicios existentes; un servicio recién añadido al archivo compose no se agrega automáticamente — ejecute Deploy from Git una vez para agregarlo.
• Proyectos multi-app: Enable staging crea una copia de prueba para cada servicio del repositorio, y “Promote all” pone en vivo todo el conjunto a la vez.
• Copias de prueba manuales: las apps no conectadas a un repositorio también pueden usar la misma mecánica de staging/promote desde el panel de entornos — vea la guía de Entornos Blue/green y el caso práctico.
• CLI: las mismas operaciones están disponibles a través de cdnctl.