Deployment pipeline : push → Staging, Promote → Production

Le pipeline en un coup d'œil

git push ──▶ [ STAGING ]  ──  Promote ──▶ [ PRODUCTION ]
              redéploie à            manuel, met en ligne
              chaque push             le build testé

• Staging est une copie réelle et séparée de votre application, avec sa propre URL de test <uid>.cdn.com.tr — servie via le edge CDN exactement comme la production.
• Production continue de servir l'ancienne version sans y toucher pendant que Staging génère et déploie. Elle ne change que lorsque vous faites un Promote.
• Roll back est toujours disponible après un Promote — le trafic/l'image et l'instantané de base de données pré-promote sont restaurés.

1 · Connectez votre dépôt (une fois)

Dans Platforms → Container Apps → App creation → Deploy from Git, connectez GitHub (recommandé — application GitHub en un clic, aucun jeton à gérer) ou utilisez une URL de dépôt + un jeton d'accès, choisissez le dépôt et la branche, cochez « Keep connected — auto-deploy on every push to this branch », puis Build & deploy. Détails complets : le guide Deploy from Git.

2 · Activer Staging

Sur la carte du pipeline, cliquez sur Enable staging. Cela crée une copie de test de chaque application du dépôt et y redirige le déploiement automatique — à partir de ce moment, les push déploient Staging, jamais Production.

• La copie de test obtient automatiquement sa propre URL de test publique (<uid>.cdn.com.tr). Si une copie créée plus tôt n'a pas encore d'URL, la carte affiche un bouton Get test URL.
• Partage des données (sous « Data sharing options », par défaut shared) : shared — Staging utilise la même base de données/Redis/stockage que la production (idéal pour les changements de code/UI) ; cloned — Staging obtient son propre MySQL avec une copie des données (sûr pour les changements de schéma) ; isolated — un démarrage à vide.
• La première ouverture d'une nouvelle URL de test peut brièvement renvoyer une 502 le temps que le edge/DNS s'activent (~une minute) — c'est normal et ponctuel.

3 · Push — Staging se déploie tout seul

• Chaque push sur la branche connectée génère l'image et la déploie sur Staging. La carte affiche le dernier push (commit + heure) et le statut de Staging en direct.
• Ouvrez la Test URL et vérifiez le nouveau build — la production sert toujours la version précédente, totalement épargnée.
• Pendant que Staging se déploie, son statut affiche deploying ; Promote reste désactivé jusqu'à ce que la copie soit en cours d'exécution.

4 · Promote — mettez la version testée en ligne

Cliquez sur Promote. La production commence immédiatement à servir la version testée — sans build et sans interruption. Un instantané automatique de la base de données est d'abord pris, afin qu'un rollback puisse aussi annuler les changements de données. En coulisses, l'un des deux mécanismes suivants est utilisé :

• Votre propre domaine rattaché → une bascule d'origine instantanée sur le edge CDN : le domaine de production est d'abord rattaché à l'application staging, puis libéré de l'ancienne — un simple déplacement de trafic, en quelques secondes, sans redémarrage.
• Production sur son sous-domaine <uid>.cdn.com.tr → l'image déjà générée et déjà testée est déployée sur l'application de production via une mise à jour progressive sans coupure (l'ancien pod continue de servir jusqu'à ce que le nouveau soit prêt). Les URL restent stables : l'URL de test est toujours celle de Staging, l'URL en ligne est toujours celle de Production.

Promote déplace le build, pas la configuration : les variables d'environnement et les secrets définis sur Staging restent sur Staging. Modifiez la configuration de production sur l'application de production.

5 · Roll back (si nécessaire)

• Après un Promote, un bouton Roll back apparaît côté Production. Un clic restaure la version précédente — la bascule de domaine est inversée (ou l'image précédente est redéployée) et l'instantané de base de données pré-promote est restauré.
• Rollback est la même opération instantanée, sans reconstruction, que Promote.

Bon à savoir

• Désactiver le pipeline : « Disable staging » sur la carte fait à nouveau déployer directement la production par les push (l'ancien comportement — peut causer des interruptions pendant les déploiements). La copie de test est conservée.
• Nouveaux services : le déploiement automatique met à jour les services existants ; un service nouvellement ajouté au fichier compose n'est pas ajouté automatiquement — exécutez Deploy from Git une fois pour l'ajouter.
• Projets multi-applications : Enable staging crée une copie de test pour chaque service du dépôt, et « Promote all » met tout l'ensemble en ligne en même temps.
• Copies de test manuelles : les applications non connectées à un dépôt peuvent tout de même utiliser les mêmes mécanismes de staging/promote depuis le panneau des environnements — voir le guide Environnements Blue/green et l'étude de cas.
• CLI : les mêmes opérations sont disponibles via cdnctl.