Azure App Service slots : valider un swap avant promotion en production

Un swap de slot App Service donne l’impression d’un mécanisme de release propre : déployer en staging, chauffer l’application, puis échanger le trafic avec la production. En pratique, le swap peut déplacer une mauvaise configuration, exposer une dépendance valable seulement en staging, casser un accès par identité managée, vider des caches ou masquer une régression derrière un rollback rapide.

Le cas d’usage est un site ou une API de production hébergé sur Azure App Service. Une nouvelle version vient d’être déployée dans un slot de staging et l’équipe s’apprête à la promouvoir. L’objectif du runbook est de décider s’il faut swapper, attendre, corriger la configuration ou revenir au slot de production courant avec assez de preuves pour expliquer la décision après coup.

Figer le contrat de release

Avant de toucher au bouton de swap, décrire ce qui doit rester stable. Un swap modifie le routage, mais le vrai risque porte sur le contrat autour des settings, des identités, des dépendances et des probes.

Release a qualifier
Nom de l'App Service et resource group
Slot source : staging
Slot cible : production
Version de build ou d'image conteneur
Run de pipeline de deploiement
Hostname public et domaines custom attendus
Dependances attendues : base, storage, API, queue, cache
Fenetre de changement et responsable rollback

Controles a prouver
Les slot settings sont correctement marques
Les secrets production-only ne partent pas en staging
Les diagnostics staging-only ne partent pas en production
L'identite managee et les RBAC sont valides pour les dependances cible
Les health probes passent par le meme chemin d'ingress que les utilisateurs
Le rollback par swap inverse est teste et documente

Ce contrat évite une confusion fréquente : une URL de staging verte ne prouve pas que l’application se comportera correctement une fois devenue production.

Comparer les settings avant le swap

Les slot settings décident quelles valeurs restent attachées au slot et quelles valeurs bougent pendant le swap. Un seul mauvais flag peut promouvoir une chaîne de connexion de staging ou laisser en production un feature flag prévu uniquement pour la validation.

APP_NAME="app-prod"
RESOURCE_GROUP="rg-app-prod"
SOURCE_SLOT="staging"
TARGET_SLOT="production"

az webapp config appsettings list --name "$APP_NAME" --resource-group "$RESOURCE_GROUP" --slot "$SOURCE_SLOT" --output json > appsettings-staging.json

az webapp config appsettings list --name "$APP_NAME" --resource-group "$RESOURCE_GROUP" --output json > appsettings-production.json

jq -r '.[] | [.name, .slotSetting, (.value | tostring | length)] | @tsv' appsettings-staging.json | sort > staging-settings.tsv
jq -r '.[] | [.name, .slotSetting, (.value | tostring | length)] | @tsv' appsettings-production.json | sort > production-settings.tsv

diff -u production-settings.tsv staging-settings.tsv || true

Le diff ne doit pas exposer les valeurs de secrets. Il doit exposer les noms, les flags de slot et la présence d’une valeur. Si DATABASE_URL, KeyVaultName, Feature__WriteMode ou APPLICATIONINSIGHTS_CONNECTION_STRING diffèrent, il faut décider si l’écart est attendu et s’il doit rester attaché au slot.

Chauffer le candidat par le vrai chemin

Un endpoint de warmup qui vérifie seulement que le process répond ne suffit pas. Le slot de staging doit prouver qu’il sait démarrer, charger sa configuration, joindre ses dépendances et répondre utilement par le même chemin gateway, DNS et TLS que la production.

STAGING_HOST="app-prod-staging.azurewebsites.net"
PROD_HOST="app.example.com"
CORRELATION_ID="swap-$(date +%Y%m%d%H%M%S)"

curl -sS -D staging-headers.txt -H "x-correlation-id: $CORRELATION_ID" "https://$STAGING_HOST/health/ready"

curl -sS -D production-headers.txt -H "x-correlation-id: $CORRELATION_ID-before" "https://$PROD_HOST/health/ready"

La probe doit être représentative mais bornée. Elle peut vérifier une lecture base de données, la connexion cache, les métadonnées d’une queue, le chargement des feature flags et l’obtention d’un token par identité. Elle ne doit pas écrire de données production depuis staging sauf si l’action est explicitement sûre.

Valider identité et dépendances

Un swap ne corrige pas magiquement l’identité. L’application peut utiliser une identité system-assigned, une identité user-assigned, des références Key Vault, Storage, SQL ou des API privées. Le slot candidat doit prouver que l’identité runtime après promotion sera bien celle attendue.

Controle avant swap
Identite managee activee sur l'app de production et le slot attendu
Client ID de l'identite user-assigned stable
References Key Vault resolues dans le slot source
Acces base ou API teste avec l'identite applicative
Dependances privees jointes par le chemin VNet Integration attendu
Feature flags n'activant pas les chemins d'ecriture avant promotion

Suspendre le swap quand
Staging fonctionne seulement avec une identite de test plus large
Les references Key Vault sont non resolues ou stale
L'acces dependance reussit depuis staging mais pas par le chemin production
La nouvelle version demande un role qui n'a pas encore propage

Si le candidat nécessite un nouveau rôle, il faut qualifier ce changement séparément. Ne cachez pas une modification d’identité dans un swap de slot.

Lire les logs comme preuves de release

La décision de swap doit s’appuyer sur les logs avant et après promotion. Garder ensemble le run de pipeline, le nom du slot, la version de build et les identifiants de corrélation.

let Window = 2h;
let CorrelationPrefix = "swap-";
AppServiceHTTPLogs
| where TimeGenerated > ago(Window)
| where CsUriStem has "/health" or CsUserAgent has "swap-probe"
| project TimeGenerated,
        Host = CsHost,
        Uri = CsUriStem,
        Status = ScStatus,
        TimeTaken,
        UserAgent = CsUserAgent
| order by TimeGenerated desc

Si Application Insights est utilisé, corréler les requêtes, dépendances et exceptions avec le même marqueur de release. Un statut HTTP vert avec des dépendances en échec n’est pas une release verte.

Décider swap, attente ou rollback

La décision doit être écrite avant que l’équipe soit sous pression. La matrice ci-dessous garde l’action limitée.

Swapper
Diff de settings relu
Slot settings corrects
Warmup vert par le chemin prevu
Identite et dependances validees
Logs sans nouvelle exception critique
Responsable et commande de rollback prets

Attendre
Derive de configuration non expliquee
Health check trop superficiel
Acces dependance via une identite de test
RBAC ou DNS requis encore en propagation
Observabilite insuffisante pour prouver le comportement candidat

Rollback apres swap
Probes production en echec apres promotion
Taux d'erreur ou echecs dependances en hausse sur la nouvelle version
Feature flag declenchant des ecritures inattendues
Parcours client en regression et correction locale plus risquee qu'un retour arriere

Un rollback par swap inverse n’est pas un échec du processus. C’est la raison pour laquelle ce chemin de release existe. Le point important est de savoir quelles preuves le déclenchent.

Exécuter et valider le swap

Exécuter le swap avec une source et une cible explicites, puis rejouer immédiatement les mêmes probes. Éviter de modifier plusieurs contrôles sans rapport pendant la même fenêtre.

APP_NAME="app-prod"
RESOURCE_GROUP="rg-app-prod"
SOURCE_SLOT="staging"
TARGET_SLOT="production"
CORRELATION_ID="swap-$(date +%Y%m%d%H%M%S)"

az webapp deployment slot swap --name "$APP_NAME" --resource-group "$RESOURCE_GROUP" --slot "$SOURCE_SLOT" --target-slot "$TARGET_SLOT"

curl -sS -D after-swap-headers.txt -H "x-correlation-id: $CORRELATION_ID-after" "https://app.example.com/health/ready"

Conserver les sorties de probes avant et après avec le ticket de déploiement. Si le rollback est nécessaire, utiliser la même commande de swap en sens inverse et rejouer les probes.

Conclusion

Les slots App Service sont utiles quand ils sont traités comme un chemin de release exploitable, pas comme un raccourci autour de la validation de production. Une décision de swap saine sépare configuration, flags de slot, warmup, identité, dépendances, logs et rollback.

Le meilleur résultat n’est pas seulement que le swap réussisse. C’est que l’équipe puisse expliquer pourquoi la promotion était sûre, ce qui a été validé après promotion et à quel moment exact un rollback aurait été déclenché.