Validation Préalable de Déploiement Azure

Cette skill valide les déploiements Bicep avant exécution, en supportant les workflows Azure CLI (az) et Azure Developer CLI (azd).

Quand Utiliser Cette Skill

• Avant de déployer une infrastructure sur Azure
• Lors de la préparation ou révision de fichiers Bicep
• Pour prévisualiser les changements qu'un déploiement apportera
• Pour vérifier que les permissions sont suffisantes pour le déploiement
• Avant d'exécuter azd up, azd provision, ou az deployment

Processus de Validation

Suivez ces étapes dans l'ordre. Continuez à l'étape suivante même si une étape précédente échoue — capturez tous les problèmes dans le rapport final.

Étape 1 : Détecter le Type de Projet

Déterminez le workflow de déploiement en vérifiant les indicateurs du projet :

1. Vérifier un projet azd : Cherchez azure.yaml à la racine du projet

   • Si trouvé → Utiliser le workflow azd
   • Si non trouvé → Utiliser le workflow az CLI

2. Localiser les fichiers Bicep : Trouvez tous les fichiers .bicep à valider

   • Pour les projets azd : Vérifiez d'abord le répertoire infra/, puis la racine du projet
   • Pour les fichiers autonomes : Utilisez le fichier spécifié par l'utilisateur ou cherchez dans les emplacements courants (infra/, deploy/, racine du projet)

3. Détection automatique des fichiers de paramètres : Pour chaque fichier Bicep, cherchez les fichiers de paramètres correspondants :

   • <filename>.bicepparam (paramètres Bicep - préféré)
   • <filename>.parameters.json (paramètres JSON)
   • parameters.json ou parameters/<env>.json dans le même répertoire

Étape 2 : Valider la Syntaxe Bicep

Exécutez Bicep CLI pour vérifier la syntaxe du modèle avant de tenter la validation du déploiement :

bicep build <bicep-file> --stdout

À capturer :

• Erreurs de syntaxe avec numéros de ligne/colonne
• Messages d'avertissement
• Statut succès/échec de la compilation

Si Bicep CLI n'est pas installé :

• Notez le problème dans le rapport
• Continuez à l'étape 3 (Azure validera la syntaxe lors de what-if)

Étape 3 : Exécuter la Validation Préalable

Choisissez la validation appropriée en fonction du type de projet détecté à l'étape 1.

Pour les Projets azd (azure.yaml existe)

Utilisez azd provision --preview pour valider le déploiement :

azd provision --preview

Si un environnement est spécifié ou si plusieurs environnements existent :

azd provision --preview --environment <env-name>

Pour Bicep Autonome (pas d'azure.yaml)

Déterminez la portée du déploiement à partir de la déclaration targetScope du fichier Bicep :

Exécutez d'abord avec le niveau de validation Provider :

# Portée groupe de ressources (plus courant)
az deployment group what-if \
  --resource-group <rg-name> \
  --template-file <bicep-file> \
  --parameters <param-file> \
  --validation-level Provider

# Portée abonnement
az deployment sub what-if \
  --location <location> \
  --template-file <bicep-file> \
  --parameters <param-file> \
  --validation-level Provider

# Portée groupe de gestion
az deployment mg what-if \
  --location <location> \
  --management-group-id <mg-id> \
  --template-file <bicep-file> \
  --parameters <param-file> \
  --validation-level Provider

# Portée tenant
az deployment tenant what-if \
  --location <location> \
  --template-file <bicep-file> \
  --parameters <param-file> \
  --validation-level Provider

Stratégie de Secours :

Si --validation-level Provider échoue avec des erreurs de permission (RBAC), réessayez avec ProviderNoRbac :

az deployment group what-if \
  --resource-group <rg-name> \
  --template-file <bicep-file> \
  --validation-level ProviderNoRbac

Notez le secours dans le rapport — l'utilisateur peut ne pas avoir les permissions de déploiement complètes.

Étape 4 : Capturer les Résultats What-If

Analysez la sortie what-if pour catégoriser les changements de ressources :

Pour les ressources modifiées, capturez les changements de propriétés spécifiques.

Étape 5 : Générer le Rapport

Créez un fichier rapport Markdown à la racine du projet nommé :

• preflight-report.md

Utilisez la structure de modèle de references/REPORT-TEMPLATE.md.

Sections du rapport :

1. Résumé - Statut global, horodatage, fichiers validés, portée cible
2. Outils Exécutés - Commandes exécutées, versions, niveaux de validation utilisés
3. Problèmes - Tous les erreurs et avertissements avec sévérité et remédiation
4. Résultats What-If - Ressources à créer/modifier/supprimer/inchangées
5. Recommandations - Étapes concrètes suivantes

Informations Requises

Avant d'exécuter la validation, rassemblez :

Si des informations requises manquent, invitez l'utilisateur avant de continuer.

Gestion des Erreurs

Consultez references/ERROR-HANDLING.md pour des conseils détaillés de gestion des erreurs.

Principe clé : Continuez la validation même en cas d'erreurs. Capturez tous les problèmes dans le rapport final.

Exigences des Outils

Cette skill utilise les outils suivants :

• Azure CLI (az) - Version 2.76.0+ recommandée pour --validation-level
• Azure Developer CLI (azd) - Pour les projets avec azure.yaml
• Bicep CLI (bicep) - Pour la validation de la syntaxe
• Azure MCP Tools - Pour les recherches de documentation et les bonnes pratiques

Vérifiez la disponibilité des outils avant de commencer :

az --version
azd version
bicep --version

Exemple de Workflow

1. Utilisateur : "Valide mon déploiement Bicep avant que je l'exécute"
2. L'agent détecte azure.yaml → projet azd
3. L'agent trouve infra/main.bicep et infra/main.bicepparam
4. L'agent exécute bicep build infra/main.bicep --stdout
5. L'agent exécute azd provision --preview
6. L'agent génère preflight-report.md à la racine du projet
7. L'agent résume les résultats à l'utilisateur

Documentation de Référence

• Validation Commands Reference
• Report Template
• Error Handling Guide