Table des matières :
- 2.89.0 vs 2.89.1 : ce que ce numéro de version implique vraiment en pratique
- Où lire les notes de version officielles 2.89.0 / 2.89.1 et ce qu’il faut en extraire
- Mettre à jour Azure CLI 2.89.x sans casser la prod : pinning, images, et CI reproductible
- Changements “à haut risque” à tester en priorité avec 2.89.0/2.89.1 (même si la release est « mineure »)
- Recette de validation : comparer 2.89.0 → 2.89.1, smoke tests Azure CLI, puis rollback propre
2.89.0 vs 2.89.1 : ce que ce numéro de version implique vraiment en pratique
Azure CLI suit une numérotation de type semver (major/minor/patch) mais, dans la vraie vie, ce n’est pas un contrat absolu : la CLI est un agrégat (core + commandes + dépendances + extensions), et certaines « petites » évolutions peuvent impacter vos scripts (format de sortie, valeurs par défaut, changement de fournisseur API, messages d’erreur). Le point à retenir pour 2.89.0/2.89.1 est donc moins « quelles features » que « quel risque d’incompatibilité sur mon automation ». C’est exactement le genre de dette technique qui explose lors d’un déploiement infra ou d’un runbook d’incident.
La différence attendue entre 2.89.0 et 2.89.1 est structurellement celle d’une version patch : corrections et ajustements, idéalement sans rupture. La définition du semver reste utile pour cadrer l’analyse :
“Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes.” — Semantic Versioning 2.0.0 (semver.org)
Ce qui compte pour vos pipelines, c’est que patch ≠ « aucun impact ». Sur Azure CLI, un patch peut suffire à casser un job si vous dépendez de comportements implicites. Exemples réalistes (déjà vus en production chez beaucoup d’équipes) :
- Parsing fragile : un champ JSON passe de
""ànull, un tableau devient vide ([]), un message d’erreur change et votre grep ne matche plus. - Defaults qui bougent : une commande commence à exiger un paramètre auparavant optionnel (ou inversement), ou une validation devient plus stricte.
- Dépendances : une mise à jour de librairies Python sous-jacentes change la manière dont une erreur HTTP est remontée.
- Extensions : vous mettez à jour la CLI mais pas une extension (ou l’inverse) → combinaison non testée.
Mini-scénario e-commerce (très concret) : vous avez un déploiement infra + appli le jeudi soir, et la nuit suivante votre runner CI est reconstruit automatiquement. Vendredi matin (jour de promo), un az keyvault secret show renvoie une erreur légèrement différente, votre script d’initialisation considère à tort que le secret “n’existe pas” et lance une création qui échoue (soft-delete/purge protection). Résultat : incident sur la chaîne de déploiement, alors que « le code n’a pas changé ».
Pour limiter ce risque, pensez « contrat d’outillage » : la version de l’Azure CLI fait partie des dépendances de votre livraison, au même titre que PHP, Terraform, Helm ou votre image Nginx/PHP-FPM.
Où lire les notes de version officielles 2.89.0 / 2.89.1 et ce qu’il faut en extraire
Le seul endroit fiable pour les release notes Azure CLI, c’est la source Microsoft/GitHub. Ne partez pas d’un copier-coller de blog (y compris celui-ci) sans recouper, parce que le changelog est parfois amendé après publication.
- Release notes 2.89.0 (GitHub)
- Release notes 2.89.1 (GitHub)
- Documentation officielle Azure CLI (Learn)
Pour accélérer l’analyse entre 2.89.0 et 2.89.1, utilisez aussi la comparaison GitHub (pratique pour repérer rapidement les commits) :
comparaison GitHub
Concrètement, quand vous lisez les notes 2.89.0/2.89.1, ne cherchez pas un inventaire exhaustif. Filtrez par impact :
- Breaking changes (quand la release les mentionne) : paramètres supprimés/renommés, valeurs par défaut modifiées, outputs JSON modifiés.
- Command modules touchés : pour un SI e-commerce, surveillez typiquement
appservice,storage,keyvault,monitor,network,aks,acr,mysql. - Extensions et dépendances : certaines équipes installent des extensions (
az extension add) et oublient qu’elles suivent leur propre cycle.
Méthode simple pour savoir si vous êtes concerné, avant même de lire les release notes : faites l’inventaire des commandes az réellement utilisées dans vos dépôts (et pas seulement “dans l’idée”).
# Exemple : lister les commandes az présentes dans un repo (à adapter)
rg -n --no-heading "^\s*az\s+" -S . | head -n 50
# Ou si vous avez des scripts Bash:
rg -n --no-heading "az\s+(group|keyvault|storage|webapp|aks|acr|monitor)\b" -S .
Ensuite, dans la release note, vous cherchez :
- vos commandes (ex.
az webapp config appsettings set) ; - les changements sur les types de sortie (
json,table,tsv) ; - les mentions de dépréciation (deprecation) ou de migration (par ex. “use RBAC instead of access policies”, etc.).
La doc Learn reste indispensable pour remettre en contexte le fonctionnement général de la CLI (auth, configuration, formats, --query/JMESPath, etc.) : Documentation Azure CLI (Learn)
Si vous avez déjà de l’historique sur le site, recoupez avec cette publication qui aide à comprendre la logique de changement côté CLI (modules sensibles, options qui apparaissent/disparaissent) : évolution des commandes Azure CLI (az appconfig et modules Batch 2.27.x).
Mettre à jour Azure CLI 2.89.x sans casser la prod : pinning, images, et CI reproductible
Pré-requis (à expliciter dans vos runbooks) : OS (Linux/Windows/macOS), droits d’admin pour installer la CLI, accès sortant vers les dépôts, et surtout une stratégie de version. Si vous déployez une boutique PrestaShop (8.2+ / 9.x, PHP 8.2–8.3) sur une infra Azure, vous avez souvent des pipelines qui gèrent à la fois l’app (artefacts, migrations) et l’infra (réseau, secrets, scaling). Une mise à jour Azure CLI non contrôlée, c’est un risque direct sur l’infra.
La règle simple : fixez la version Azure CLI dans vos runners.
- Sur un runner auto-hébergé : installez explicitement la version (package manager + version lock si possible) et surveillez.
- En CI : préférez une image Docker versionnée.
Exemple (Docker) :
# Exemple de pattern : exécuter une commande az dans un conteneur versionné
docker run --rm -it \
mcr.microsoft.com/azure-cli:2.89.1 \
az --version
Pour aller un cran plus loin (supply chain + reproductibilité), fixez l’image par digest plutôt que par tag (le tag peut être retagué, même si c’est rare sur des images officielles) :
# Pattern (digest à remplacer par le vôtre après vérification)
docker run --rm -it \
mcr.microsoft.com/azure-cli:2.89.1@sha256:<DIGEST> \
az --version
Dans GitHub Actions / GitLab CI / Azure DevOps, l’approche la plus robuste reste « image + scripts » plutôt que « installer au runtime ». Ça rejoint les bonnes pratiques DevOps/IaC : environnements reproductibles, idempotence, auditabilité. Pour cadrer cette logique côté infra, vous pouvez vous appuyer sur : Infrastructure as Code avec Terraform et conteneurs (approche reproductible).
Checklist « pinning » à intégrer dans vos runbooks (courte mais efficace) :
- [ ] La CLI est versionnée (tag/digest Docker, ou package pin).
- [ ] La version exécutée est loggée au début de chaque job (
az --version). - [ ] Les extensions sont versionnées (ou explicitement figées).
- [ ] Un job “canary” teste la nouvelle version en staging avant prod.
- [ ] Une procédure de rollback est documentée (1 commande, pas 10).
Enfin, ne mélangez pas n’importe comment CLI et extensions. Si votre pipeline exécute az extension add --name X sans version, vous recréez le problème « latest ». Standardisez :
az extension add --name <extension> --version <x.y.z>
az extension list -o table
C’est particulièrement important si vous automatisez des déploiements applicatifs de type « PrestaShop sur AKS » ou « PrestaShop containerisé » : l’outillage (CLI/extension) devient une dépendance de build/déploiement. Pour le contexte Kubernetes côté PrestaShop : checklist GitOps et pièges d’une migration PrestaShop vers Kubernetes.
Changements “à haut risque” à tester en priorité avec 2.89.0/2.89.1 (même si la release est « mineure »)
Premier axe : authentification et identité. La plupart des scripts Azure CLI finissent par s’authentifier via az login (humain), un service principal (CI), ou une managed identity (VM/Container Apps/AKS). Les régressions et changements de comportement touchent typiquement la gestion des tokens, les scopes, ou la manière dont la CLI sélectionne un abonnement/tenant par défaut. Pour des environnements multi-subscriptions (staging/prod), testez systématiquement :
az account show
az account list -o table
az account set --subscription "$AZ_SUBSCRIPTION_ID"
Bon réflexe : faites échouer explicitement si la souscription active n’est pas celle attendue (c’est l’une des causes les plus fréquentes de “déploiement réussi mais au mauvais endroit”) :
CURRENT_SUB="$(az account show --query id -o tsv)"
test "$CURRENT_SUB" = "$AZ_SUBSCRIPTION_ID"
Sur la gestion des secrets, l’objectif est de réduire la présence de credentials statiques dans les pipelines. Microsoft documente les managed identities et, côté CI, les mécanismes modernes comme la fédération d’identité (selon votre plateforme). Référence générale (utile pour cadrer le modèle) : Managed identities overview
Deuxième axe : format de sortie et parsing. Beaucoup de pipelines font du jq sur du JSON retourné par az. Un changement (même minime) de champ, ou une valeur null devenue [], casse une extraction. Votre mitigation : ajoutez des tests « contractuels » sur les champs que vous consommez, et forcez l’output.
# Standardiser l'output
az group show -n "$RG" -o json
# Exemple de garde-fou sur un champ attendu
az webapp show -g "$RG" -n "$APP" -o json | jq -e '.state == "Running"'
Une autre tactique (souvent plus stable qu’un gros JSON) : extraire uniquement la donnée nécessaire via --query et -o tsv.
STATE="$(az webapp show -g "$RG" -n "$APP" --query state -o tsv)"
test "$STATE" = "Running"
Troisième axe : API versions et valeurs par défaut. Azure CLI appelle des APIs Azure qui ont leurs versions et dépréciations. Même si votre script ne change pas, une CLI plus récente peut utiliser une version d’API différente (et exposer de nouveaux champs ou modifier une validation). Sur des workloads e-commerce, les zones sensibles sont souvent :
az storage(uploads batch d’assets, lifecycle management, SAS)az keyvault(policies vs RBAC, soft-delete/purge-protection)az appservice(settings, slots, déploiements)az monitor(alert rules, diagnostic settings)
Quatrième axe (souvent oublié) : contexte “région / géographie”. Si vous opérez en France, vous pouvez avoir des contraintes de localisation des données et, en pratique, des déploiements ciblés sur des régions Azure françaises (par exemple France Central). Une mise à jour CLI peut révéler une validation plus stricte sur un SKU/feature qui n’est pas disponible dans une région donnée, ou une différence de comportement sur des ressources “paired region”. Dans vos tests de non-régression, vérifiez donc aussi :
- la région effective des ressources critiques (Key Vault, Storage, App Service/Plan, AKS) ;
- l’activation de features qui peuvent être régionales (certains types de chiffrement, options réseau, etc.).
Table “priorités de test” (orientée automation) :
| Zone | Risque typique | Exemple de test CLI |
|---|---|---|
| Identité / souscription | déploiement sur le mauvais abonnement/tenant | az account show --query "{tenant:tenantId, sub:id}" |
| Key Vault | RBAC/policies, erreurs soft-delete | az keyvault show ... + test lecture secret |
| Storage | SAS/permissions, endpoints, firewall | az storage account show ... --query |
| App Service | settings/slots, format de sortie | az webapp show ... --query state |
| Réseau | DNS privé, Private Endpoint, règles NSG | az network vnet show ... |
| Monitor | règles/diagnostics modifiées | az monitor diagnostic-settings list ... |
Si votre PrestaShop dépend d’un stockage objet pour les médias ou d’un CDN, couplez ces tests avec un monitoring d’erreurs applicatives côté front/back (TTFB, 5xx, latence). Le site a déjà des éléments sur la supervision : supervision temps réel (Netdata) sur Kubernetes/Docker et cloud.
Recette de validation : comparer 2.89.0 → 2.89.1, smoke tests Azure CLI, puis rollback propre
Objectif : transformer une mise à jour « outillage » en changement maîtrisé, avec une preuve. La recette minimale : exécuter les mêmes commandes avec 2.89.0 puis 2.89.1 sur un environnement de staging, et comparer (exit codes + JSON + logs). Le plus simple est de versionner les tests comme du code.
Exemple de squelette Bash (à adapter) :
set -euo pipefail
CLI_VERSION="$1" # 2.89.0 ou 2.89.1
IMAGE="mcr.microsoft.com/azure-cli:${CLI_VERSION}"
run_az() {
docker run --rm \
-e AZURE_CONFIG_DIR=/tmp/azconfig \
-v "$PWD/tests:/tests" \
"$IMAGE" bash -lc "$*"
}
# 1) Vérifier la version
run_az "az --version"
# 2) Auth non-interactive (exemple : managed identity sur runner Azure)
# run_az "az login --identity"
# 3) Smoke test : ressources critiques
run_az "az group show -n $RG -o json"
run_az "az keyvault show -n $KV -g $RG -o json"
run_az "az storage account show -n $SA -g $RG -o json"
Pour rendre la comparaison réellement exploitable, ajoutez un diff “stable” (tri JSON) afin d’isoler les différences significatives :
# Exemple : capturer et comparer une sortie JSON triée
run_az "az keyvault show -n $KV -g $RG -o json" | jq -S . > "out/keyvault-${CLI_VERSION}.json"
# Puis, après avoir généré les deux fichiers:
diff -u out/keyvault-2.89.0.json out/keyvault-2.89.1.json || true
Bonnes pratiques de smoke tests orientés e-commerce (PrestaShop) : vos tests doivent refléter la réalité applicative, pas seulement « l’infra existe ». Ajoutez (au minimum) :
- un test HTTP sur
/et une URL plus « dynamique » (ex. page panier/compte selon votre routage) ; - un test de connectivité DB (même simple) et cache (Redis si présent) ;
- un test de lecture d’un secret attendu (sans l’afficher dans les logs) ;
- une vérification que le déploiement cible la bonne région (utile si vous segmentez France/Europe).
Les articles internes qui cadrent bien la logique « recette perf + risques de régression » côté PHP/Symfony : audit performance PHP/Symfony avec profilage et déploiement Symfony 7 (PHP-FPM, Nginx, cache, opcache).
Le rollback doit être aussi simple que l’upgrade :
- Si vous utilisez Docker : rollback = repasser le tag (ou digest)
mcr.microsoft.com/azure-cli:2.89.0. - Si vous installez via package manager : documentez la commande de downgrade et assurez-vous que la version précédente est disponible (ou mise en cache dans vos artefacts internes).
- Si vous installez “au runtime” (à éviter) : au minimum, cachez l’artefact d’installation et loggez la version installée.
Dans tous les cas : journalisez la version de la CLI exécutée dans les logs de pipeline (az --version en début de job) et dans vos artefacts d’audit. Ça évite les enquêtes inutiles quand un runbook tombe à 02:00.
Dernier point : si vous provisionnez via ARM/Bicep/Terraform, séparez clairement plan et apply, et utilisez les mécanismes de prévisualisation (what-if côté ARM/Bicep) avant d’appliquer. Une mise à jour Azure CLI ne doit jamais être la première fois que vous découvrez une différence de comportement en production — surtout sur un environnement e-commerce où un mauvais paramétrage réseau ou Key Vault peut vous mettre hors-ligne immédiatement.
