Contexte de la migration

Une équipe a renommé les déploiements back‑end d’un environnement non‑production. Les définitions de pipeline Azure DevOps ont été mises à jour avec les nouveaux noms d’image, le nom du chart Helm, le nom de release Helm et les ressources Kubernetes. Malgré ces changements, l’ouverture d’une ancienne release Classic a affiché le bouton Redeploy, révélant que les tâches inline conservaient les valeurs d’origine.

Mécanisme de stockage des releases Classic

Microsoft décrit une release Classic comme un snapshot du graphe de tâches nécessaire à l’exécution. Chaque release stocke les paramètres capturés à sa création : chemin du dépôt d’image, nom du chart, nom de release Helm et variables. La modification d’une définition ne réécrit pas les graphes déjà stockés. Ainsi, les 45 releases identifiées parmi cinq définitions conservaient les anciennes combinaisons, même si la définition actuelle affichait uniquement les nouvelles valeurs.

helm install myapp ./chart \
    --install \
    --set image.repository=old.registry.io/app

Le flag --install indique à Helm d’installer lorsqu’il ne trouve pas le nom de release. Si le nom a été retiré, une redeployment déclenchera une nouvelle installation sous l’identité obsolète, au lieu d’une mise à jour.

Risques liés aux releases obsolètes

Sans les options --atomic ou --cleanup-on-fail, Helm laisse les objets Kubernetes (Secret, ServiceAccount, Service, Deployment) en place lorsqu’une installation échoue. Dans le scénario testé, la première tentative a créé ces objets, puis un webhook d’admission a rejeté le second ingress du fait du doublon de route. Les objets résiduels restent visibles par les opérateurs et le Service peut rester accessible en interne, même si le pod ne démarre pas à cause d’un ImagePullBackOff causé par la suppression du dépôt d’image ancien.

Stratégies de nettoyage et de migration

1. Utiliser l’API Release pour filtrer les releases créées avant le timestamp de cut‑over : 

curl -u user:PAT \
  "https://dev.azure.com/org/_apis/release/releases?definitionId=123&api-version=6.0"
2. Inspecter chaque payload afin de vérifier les scripts stockés, les noms de release Helm, les chemins d’image et les valeurs de variables. 3. Supprimer les dépôts d’image retirés ; une release stale ne pourra alors récupérer l’image et restera en ImagePullBackOff. 4. Abandonner les releases obsolètes via l’API (statut Abandoned). Le test d’abandon d’une release a renvoyé l’erreur VS402966, confirmant que la transition est unidirectionnelle : le statut ne peut pas repasser à Active. 5. Vérifier que les releases actives post‑cut‑over pointent vers les nouvelles ressources et que les workloads fonctionnent correctement.

En combinant filtrage programmatique, inspection du graphe de tâches et suppression des artefacts obsolètes, il est possible de garantir que la migration du pipeline ne laisse pas de chemins d’exécution rétroactifs capables de perturber le cluster Kubernetes.