Azure DevOps : diagnostiquer un Variable Group avant de relancer le déploiement

Une pipeline Azure DevOps peut échouer après un changement qui ne ressemble pas à un déploiement : une variable modifiée, un secret expiré, un lien Key Vault cassé, un scope déplacé, une autorisation de library retirée ou un override passé au moment du run. La tentation est de relancer la pipeline après avoir “corrigé la valeur”. En production, ce raccourci peut propager une mauvaise configuration sur plusieurs environnements.

Le cas d’usage est une pipeline release-prod qui déploie une API Azure et lit un Variable Group partagé : URL d’API interne, nom de Key Vault, feature flags, identifiants de connexion, endpoints de télémétrie et paramètres de rollback. Le déploiement échoue sur une étape d’authentification ou de health check. L’objectif du runbook est de décider si la pipeline peut être relancée, si le Variable Group doit être rollbacké, si un secret doit être restauré, ou si le déploiement doit rester bloqué jusqu’à clarification du contrat de configuration.

Figer le contrat de configuration

Commencez par traiter le Variable Group comme une dépendance de production. Il ne suffit pas de savoir qu’une variable existe. Il faut connaître son usage, son environnement cible, son propriétaire, son mode de mise à jour et son effet quand elle change.

pipeline: release-prod
environment: production
variable_group: vg-api-prod
linked_key_vault: kv-prod-app
last_successful_run: 2026-07-21T21:14:00Z
failed_run: 2026-07-22T05:40:00Z

configuration_contract:
variables_used_by_deploy:
  - API_BASE_URL
  - KEY_VAULT_NAME
  - FEATURE_MODE
  - APPINSIGHTS_CONNECTION_STRING
  - ROLLBACK_SLOT
secrets_used_by_runtime:
  - DB_CONNECTION
  - PARTNER_API_TOKEN
expected_scope:
  project: platform-prod
  pipelines:
    - release-prod
    - hotfix-prod
owners:
  technical: platform-engineering
  operational: sre-oncall
rollback_reference:
  source: last successful run and approved change ticket

Cette étape évite deux erreurs fréquentes : relancer avec une valeur corrigée mais non validée, ou modifier un Variable Group partagé sans mesurer les autres pipelines qui le consomment.

Comparer le run échoué au dernier run sain

Le diagnostic utile commence par une comparaison. La pipeline, le commit, le template YAML, le Variable Group, les secrets résolus et les paramètres de run peuvent tous avoir changé entre deux exécutions.

Comparer avant relance
Commit ou tag deploye
Version du template YAML
Variable Groups references par la pipeline
Variables override passees au run
Environnement Azure DevOps cible
Service connection utilisee
Key Vault lie et liste des secrets resolus
Approbations et checks traverses
Agent ou pool d'execution
Fenetre de changement et demande associee

Bloquer la relance quand
Le run echoue ne lit pas le meme Variable Group
Une variable runtime masque la valeur de la library
Le secret est resolu mais pointe vers une mauvaise version
Le groupe est partage avec une autre pipeline critique
Le dernier run sain n'est pas identifiable

Un échec après changement de configuration ne se corrige pas en relançant à l’aveugle. La relance doit reproduire un état compris, pas espérer tomber sur une valeur redevenue correcte.

Séparer variable simple, secret et référence Key Vault

Un Variable Group mélange souvent plusieurs natures de données. Une variable simple peut être lue dans les logs. Un secret est masqué mais peut être vide, expiré ou mal encodé. Une référence Key Vault dépend d’une autorisation Azure DevOps, d’une identité, d’un nom de secret et parfois d’une version.

Variable simple
Symptomes: mauvaise URL, feature flag inattendu, nom de ressource incorrect
Decision: corriger ou rollbacker la valeur avec impact consommateur documente

Secret Azure DevOps
Symptomes: valeur masquee mais authentification refusee, chaine vide, rotation incomplete
Decision: restaurer la version connue ou relancer seulement apres test borne

Secret lie a Key Vault
Symptomes: secret introuvable, acces refuse, version desactivee, firewall ou reseau en cause
Decision: verifier Key Vault, identite et version avant de toucher la pipeline

Override de run
Symptomes: pipeline saine avec mauvais parametre manuel
Decision: relancer avec parametre explicite et bloquer l'override libre si recurrent

Scope ou autorisation library
Symptomes: pipeline cannot access variable group, approval inattendue, permission refusee
Decision: restaurer le scope minimal, pas ouvrir la library a tout le projet

Le point important est de ne pas élargir les permissions pour masquer un problème de configuration. Si le secret existe mais que la pipeline ne doit pas y accéder, le bon état est peut-être le blocage.

Vérifier les accès et l’audit avant correction

Une modification de Variable Group doit laisser une trace exploitable : qui a changé quoi, quand, depuis quel ticket, avec quelle validation. Sans audit, la correction devient une seconde dérive.

ORG="https://dev.azure.com/example"
PROJECT="platform-prod"
GROUP_ID="42"

az devops configure --defaults organization="$ORG" project="$PROJECT"

az pipelines variable-group show --group-id "$GROUP_ID" --output json

az pipelines runs list --pipeline-name "release-prod" --top 5 --output table

# Completer avec l'audit Azure DevOps ou les logs d'organisation disponibles.
# Conserver l'heure du changement, l'auteur, le groupe touche et le run impacte.

Si le groupe est lié à Key Vault, vérifiez aussi côté Azure que le secret est actif, que la version attendue existe, et que la politique réseau ou RBAC n’a pas changé dans la même fenêtre.

VAULT="kv-prod-app"
SECRET="PARTNER_API_TOKEN"

az keyvault secret show --vault-name "$VAULT" --name "$SECRET" --query "{id:id,enabled:attributes.enabled,created:attributes.created,updated:attributes.updated,recoveryLevel:attributes.recoveryLevel}" --output json

az keyvault secret list-versions --vault-name "$VAULT" --name "$SECRET" --query "[].{id:id,enabled:attributes.enabled,created:attributes.created,updated:attributes.updated}" --output table

Le diagnostic doit prouver si la pipeline lit une mauvaise valeur, ne peut plus lire la valeur, ou lit une valeur correcte mais échoue plus loin.

Corréler pipeline, déploiement et runtime

Un Variable Group n’est pas valide parce que la pipeline le lit. Il est valide si le déploiement et le runtime confirment la configuration attendue. Corrélez le run Azure DevOps avec Azure Activity, les logs applicatifs et les checks de santé.

let DeploymentStart = datetime(2026-07-22T05:40:00Z);
let DeploymentEnd = datetime(2026-07-22T06:05:00Z);
AzureActivity
| where TimeGenerated between ((DeploymentStart - 10m) .. (DeploymentEnd + 20m))
| where Caller has_any ("AzureDevOps", "release-prod", "00000000-0000-0000-0000-000000000000")
| project TimeGenerated,
        OperationNameValue,
        ActivityStatusValue,
        Caller,
        ResourceGroup,
        ResourceId,
        CorrelationId,
        Properties
| order by TimeGenerated asc

Ajoutez ensuite les logs de l’application ou du health check avec le même intervalle. Un 401 runtime après un déploiement peut venir d’un secret, mais aussi d’une identité managée, d’un scope API, d’un cache applicatif ou d’une configuration non rechargée.

Décider relance, rollback ou blocage

La sortie du runbook doit être une décision courte et défendable. Une relance n’est acceptable que si l’état de configuration est prouvé, que le périmètre est borné et que le rollback est prêt.

Relancer la pipeline
Le Variable Group attendu est identifie
La valeur corrigee ou restauree est approuvee
Les secrets Key Vault sont actifs et lisibles
Les overrides de run sont explicites
Le dernier run sain sert de reference

Rollbacker le Variable Group
La derive de valeur est la cause probable
Plusieurs pipelines consomment le groupe
La version precedente est connue
La correction applicative prendrait plus de temps que le retour arriere

Bloquer le deploiement
L'auteur ou la raison du changement est inconnue
La valeur attendue n'est pas documentee
Le secret a peut-etre ete compromis
Le groupe est trop partage pour une correction rapide
La pipeline masquerait une erreur d'approbation ou de permission

Le rollback le plus sûr peut être de restaurer le Variable Group à la version du dernier run sain, puis de rejouer seulement le stage de validation. Si la pipeline ne permet pas cette granularité, le problème est aussi dans le design du déploiement.

Ajouter un garde-fou durable

Après l’incident, évitez de laisser le Variable Group comme une boîte noire. Les variables critiques doivent avoir un propriétaire, un environnement, une règle de changement et un test de consommation.

guardrails:
ownership:
  every_variable_has_owner: true
  production_group_has_change_ticket: true
scope:
  no_cross_environment_group: true
  pipeline_access_is_explicit: true
validation:
  dry_run_stage_reads_configuration: true
  health_check_uses_same_values: true
  rollback_values_are_documented: true
secrets:
  key_vault_link_preferred_for_rotated_secrets: true
  secret_version_change_is_a_deployment_signal: true
audit:
  variable_group_change_is_reviewed: true
  failed_run_keeps_configuration_snapshot: true

Ces garde-fous ne rendent pas la configuration immuable. Ils rendent ses changements lisibles et réversibles.

Conclusion

Un Variable Group Azure DevOps est une surface de production. Il influence le code déployé, les secrets résolus, les dépendances appelées, les feature flags et parfois le rollback lui-même.

Avant de relancer une pipeline, prouvez le groupe lu, la valeur effective, la version de secret, le scope, l’audit et les signaux runtime. La bonne décision peut être une relance bornée, un rollback de configuration, une restauration de secret, ou un blocage assumé jusqu’à ce que le contrat de configuration soit à nouveau exploitable.