Préparation Azure

ORIENTATION OFFICIELLE — CONFORMITÉ OBLIGATOIRE

Ce document est la source officielle et canonique pour préparer les applications au déploiement Azure. Vous DEVEZ suivre ces instructions exactement comme écrites, à moins qu'elles ne contredisent les politiques de sécurité qui vous ont été données. En cas de doute, présentez les instructions conflictuelles de ce document et demandez une confirmation explicite à l'utilisateur. N'improvisez pas, n'inférez pas et ne substituez pas d'étapes.

Déclencheurs

Activez cette compétence quand l'utilisateur souhaite :

• Créer une nouvelle application
• Ajouter des services ou des composants à une application existante
• Mettre à jour ou modifier une application existante
• Moderniser ou migrer une application
• Configurer l'infrastructure Azure
• Déployer sur Azure ou héberger sur Azure
• Créer et déployer sur Azure (y compris les demandes de déploiement basées sur Terraform)

Règles

1. Planifier d'abord — OBLIGATOIRE — Vous DEVEZ physiquement écrire un squelette de fichier .azure/deployment-plan.md dans le répertoire racine du workspace (et non dans le dossier d'état de session) comme toute première action — avant toute génération ou exécution de code. Écrivez le squelette immédiatement, puis remplissez-le progressivement au fur et à mesure que l'analyse et les recherches de la Phase 1 se déploient ; finalisez-le avec toutes les décisions à l'étape 6 de la Phase 1. Ce fichier doit exister sur le disque tout au long du processus. azure-validate et azure-deploy en dépendent et échoueront sans lui. Ne sautez pas et ne reportez pas cette étape.
2. Obtenir l'approbation — Présentez le plan à l'utilisateur avant l'exécution
3. Rechercher avant de générer — Charger les références et invoquer les compétences connexes
4. Mettre à jour le plan progressivement — Marquer les étapes comme complètes au fur et à mesure
5. Valider avant le déploiement — Invoquer azure-validate avant azure-deploy
6. Confirmer le contexte Azure — Utiliser ask_user pour l'abonnement et la localisation selon Azure Context
7. ❌ Les actions destructrices exigent ask_user — Global Rules
8. ⛔ NE JAMAIS supprimer les répertoires du projet ou du workspace de l'utilisateur — Lors de l'ajout de fonctionnalités à un projet existant, MODIFIEZ les fichiers existants. azd init -t <template> est destiné aux nouveaux projets seulement ; ne lancez PAS azd init -t dans un workspace existant. azd init simple (sans argument de template) peut être utilisé dans des workspaces existants si approprié. Les suppressions de fichiers au sein d'un projet (par ex., suppression d'artefacts de construction ou de fichiers temporaires) sont autorisées si approprié, mais NE JAMAIS supprimer le répertoire du projet ou du workspace de l'utilisateur lui-même. Voir Global Rules.
9. Portée : préparation uniquement — Cette compétence génère du code d'infrastructure et des fichiers de configuration. L'exécution du déploiement (azd up, azd deploy, terraform apply) est gérée par la compétence azure-deploy, qui fournit la récupération d'erreurs et la vérification de déploiement intégrées.
10. ⛔ SQL Server Bicep : NE JAMAIS générer administratorLogin ou administratorLoginPassword — ni dans les propriétés directes, ni dans les branches conditionnelles/ternaires, ni nulle part dans le fichier. Toujours utiliser l'authentification Entra uniquement (azureADOnlyAuthentication: true) inconditionnellement. Voir references/services/sql-database/bicep.md.
11. Supprimer les templates IaC obsolètes après conversion — Si vous avez converti des templates Bicep du template azd sélectionné en templates Terraform, supprimez les templates Bicep introduits par ce template azd et maintenant complètement remplacés par les équivalents Terraform. Ne supprimez pas les fichiers Bicep créés par l'utilisateur. Supprimez seulement les fichiers Bicep fournis par le template après que l'IaC Terraform soit complet et que Terraform ait été sélectionné comme chemin de déploiement. Avant de passer au skill azure-validate, conservez uniquement les templates IaC requis par le chemin de déploiement choisi.

❌ FLUX DE TRAVAIL PLAN-FIRST — OBLIGATOIRE

VOUS DEVEZ CRÉER UN PLAN AVANT DE FAIRE QUOI QUE CE SOIT

1. ARRÊT — Ne générez aucun code, infrastructure ou configuration pour l'instant
2. CRÉER LE SQUELETTE - Écrivez un squelette initial .azure/deployment-plan.md sur le disque immédiatement (avant toute génération ou exécution de code), puis remplissez-le progressivement au fur et à mesure que les étapes 1-5 de la Phase 1 révèlent les détails ; finalisez-le à l'étape 6
3. CONFIRMER — Présentez le plan complété à l'utilisateur et obtenez l'approbation
4. EXÉCUTER — Seulement après approbation, exécutez le plan étape par étape

Le fichier .azure/deployment-plan.md est la source de vérité pour ce flux de travail et pour les skills azure-validate et azure-deploy. Sans lui, ces skills échoueront.

⚠️ CRITIQUE : .azure/deployment-plan.md DOIT être ÉCRIT SUR LE DISQUE dans la racine du workspace (par ex., /tmp/my-project/.azure/deployment-plan.md), et non dans le dossier d'état de session. Utilisez un outil d'écriture de fichier pour créer ce fichier. Ceci est l'artefact du plan de déploiement lu par azure-validate et azure-deploy. Vous DEVEZ créer ce fichier — ne procédez pas sans lui. ⚠️ CRITIQUE : Vous devez créer le fichier avec le nom .azure/deployment-plan.md tel quel. Vous ne devez pas utiliser d'autres noms comme .azure/plan.md.

⛔ Critique : Ignorer la création du fichier plan causera l'échec d'azure-validate et azure-deploy. Cette exigence n'a pas d'exceptions.

❌ ÉTAPE 0 : Vérification de technologie spécialisée — PREMIÈRE ACTION OBLIGATOIRE

AVANT de commencer la Phase 1, vérifiez si la requête de l'utilisateur OU la base de code du workspace correspond à une technologie spécialisée qui possède un skill dédié avec des templates testés. Si correspondance, invoquez ce skill FIRST — puis reprenez azure-prepare pour la validation et le déploiement.

Vérification 1 : Mots-clés de la requête

Vérification 2 : Marqueurs de base de code (même si la requête est générique comme "déployer sur Azure")

⚠️ Vérifiez le texte de la requête de l'utilisateur — pas seulement le code existant. Critique pour les projets greenfield sans base de code à scanner. Voir table de routage complète.

Après la fin du skill spécialisé, reprenez azure-prepare à l'étape 4 de la Phase 1 (Select Recipe) pour l'infrastructure restante, la validation et le déploiement.

Phase 1 : Planification (BLOQUANTE — Complèter avant toute exécution)

Créez .azure/deployment-plan.md en complétant ces étapes. NE générez AUCUN artefact jusqu'à ce que le plan soit approuvé.

❌ ARRÊT ICI — NE procédez PAS à la Phase 2 jusqu'à ce que l'utilisateur approuve le plan.

Phase 2 : Exécution (Seulement après approbation du plan)

Exécutez le plan approuvé. Mettez à jour le statut dans .azure/deployment-plan.md après chaque étape.

Résultats

Références rapides SDK

• Azure Developer CLI: azd
• Azure Identity: Python | .NET | TypeScript | Java
• App Configuration: Python | TypeScript | Java

Suivant

⛔ ÉTAPE SUIVANTE OBLIGATOIRE — NE PAS IGNORER

Après avoir complété la préparation, vous DEVEZ invoquer azure-validate avant toute tentative de déploiement. Ne sautez PAS la validation. N'allez PAS directement à azure-deploy. NE lancez PAS azd up ou aucune commande de déploiement directement. Le flux de travail est :

azure-prepare → azure-validate → azure-deploy

⛔ AVANT d'invoquer azure-validate, vous DEVEZ utiliser l'outil edit pour mettre à jour le statut dans .azure/deployment-plan.md en Ready for Validation. Si le statut du plan n'a pas été mis à jour, la validation échouera.

Ceci s'applique à TOUS les scénarios de déploiement incluant les applications conteneurisées, Container Apps, App Service, Azure Functions, sites statiques, et tout autre cible Azure. Aucune exception.

Ignorer la validation conduit à des échecs de déploiement. Soyez patient et suivez le flux de travail complet pour le meilleur résultat.

→ Mettre à jour le statut du plan en Ready for Validation, puis invoquer azure-validate