D'un git push à la production — sans la peur

1. Connectez le dépôt une seule fois — le pipeline apparaît

L'application d'exemple est une petite application web d'arbre généalogique (un service Node derrière un conteneur). Connecter son dépôt GitHub constitue toute la configuration :

• Sur Platforms → Container Apps, connectez GitHub et choisissez le dépôt et la branche (main).
• Cela transforme l'application en Deployment pipeline : un environnement Staging (une copie de test sur sa propre URL ca-*.cdn.com.tr) et Production, avec un bouton Promote entre les deux.
• Désormais, chaque push se déploie automatiquement sur Staging — vous ne touchez jamais à la production en poussant du code.

2. Chaque push atterrit sur Staging — la production continue de servir

Voici la même application dans les deux environnements, au même instant. Regardez l'horodatage du build dans le pied de page : Staging a déjà le nouveau build issu du dernier push, tandis que Production sert encore le précédent. Rien n'a été reconstruit sur l'application de production, donc aucune interruption et aucun 504 pendant que le nouveau build compilait.

• Staging a généré et déployé automatiquement le dernier commit — accessible sur sa propre URL de test.
• Production n'est pas touchée : même build en cours d'exécution, même domaine actif, sans interruption.
• Vous testez le nouveau build dans un environnement réel et isolé avant qu'un seul utilisateur de production ne le voie.

3. Vérifiez sur la véritable URL Staging

Staging est une copie réellement fonctionnelle de l'application, sur son propre sous-domaine — même image, mêmes add-ons — vous pouvez donc naviguer dans le vrai changement, pas une maquette. Vous n'avancez que lorsque tout est correct.

• Ouvrez l'URL de test Staging depuis la carte du pipeline et testez le changement de bout en bout.
• Quelque chose est cassé ? Poussez simplement un correctif — Staging redéploie, Production reste protégée.

4. Promote : un clic, zéro reconstruction

Promote ne génère rien. Il bascule l'origine du domaine de production vers le build Staging déjà en cours d'exécution — un changement instantané et atomique. Le build que vous avez testé est, octet pour octet, celui qui passe en ligne.

• Cliquez sur Promote sur la carte du pipeline — la production sert désormais exactement le build que vous avez vérifié sur Staging.
• Comme il s'agit d'une bascule d'origine de domaine (et non d'une reconstruction), la transition est instantanée et sans interruption.
• Rollback fonctionne à l'identique, en sens inverse : un clic ramène la production au build précédent (avec un instantané de la base de données si l'application en possède une).

Le même pipeline depuis le terminal (cdnctl)

Tout ce qui précède est scriptable — pratique pour la CI. Le panneau et cdnctl pilotent les mêmes 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>

Pourquoi c'est sûr par conception

• Pousser du code ne peut jamais casser la production — le déploiement automatique ne cible que Staging.
• Ce que vous promouvez est exactement ce que vous avez testé (aucune reconstruction entre le test et la mise en ligne).
• La bascule et le rollback sont des échanges d'origine de domaine instantanés, pas des redéploiements lents.
• Les builds se déroulent en parallèle, donc le site en ligne ne renvoie jamais de 504 pendant la compilation.

Guides de référence : Deployment pipeline · Deploy from Git · Environnements Blue/green.