Bonnes pratiques Azure Developer CLI

Utilisez cette skill pour produire des projets azd maintenables, sécurisés et conscients de l'environnement. Préférez les conventions du repository quand elles sont déjà cohérentes, et apportez le plus petit changement complet qui améliore le projet.

Commencez par la découverte du repository

Avant de modifier :

1. Trouvez azure.yaml, le chemin configuré infra.path, les projets source, les scripts de déploiement, .gitignore, et les définitions de pipeline.
2. Lisez azure.yaml avant de déduire les services ou le fournisseur IaC.
3. Identifiez si la tâche consiste à créer, migrer, examiner, déployer ou dépanner.
4. Identifiez l'environnement actif uniquement quand une opération spécifique à l'environnement est requise.
5. Lisez la référence pertinente :
   • Disposition du repository ou azure.yaml : references/project-structure.md
   • Bicep, Terraform, paramètres, outputs, ou environnements : references/iac-and-environments.md
   • Secrets, hooks, CI/CD, déploiement ou dépannage : references/security-cicd-operations.md
   • Détails produit qui ont pu changer : references/official-docs.md

Ne supposez pas le chemin infra par défaut, le fournisseur Bicep par défaut, ou un seul service quand azure.yaml dit autre chose.

Appliquez les garde-fous de sécurité

• Ne committez jamais .azure, les fichiers .env d'environnement, les credentials, les outputs de déploiement contenant des secrets, l'état Terraform local, ou les artefacts de déploiement générés.
• Ne mettez jamais de secrets en dur dans azure.yaml, les fichiers de paramètres IaC, les hooks, le contrôle de source, les arguments de commande qui seront enregistrés, ou les outputs IaC.
• Préférez les identités managées et RBAC. Utilisez les références Key Vault et azd env set-secret quand un secret est inévitable.
• Avant une commande qui peut créer, modifier ou supprimer des ressources Azure, confirmez l'environnement cible, la souscription, le tenant, la région, et la portée attendue.
• Traitez une demande utilisateur explicite de déployer, approvisionner, détruire ou configurer un pipeline comme approbation pour cette action nommée. Sinon, demandez avant d'exécuter azd up, azd provision, azd deploy, azd down, ou azd pipeline config.
• Ne remplacez pas Bicep par Terraform, Terraform par Bicep, ou un service d'hébergement établi à moins que l'utilisateur ne demande ce changement architectural.
• Préservez les ressources et l'état possédés en dehors du projet azd actuel.

Utilisez ces valeurs par défaut

Flux de travail d'implémentation

1. Modélisez l'application

• Définissez une entrée services pour chaque composant indépendamment déployable.
• Gardez les clés de service stables car elles participent à la découverte de ressources et au déploiement.
• Mappez chaque service à son project, language, et host réels.
• Conservez l'infrastructure partagée dans IaC plutôt que d'inventer un faux service déployable.
• Déclarez les dépendances avec les champs supportés azure.yaml au lieu de vous fier à l'ordre des fichiers.

2. Modélisez l'infrastructure

• Gardez main.bicep ou main.tf comme point d'entrée d'orchestration.
• Divisez l'infrastructure réutilisable ou indépendamment compréhensible en modules.
• Paramétrez les valeurs spécifiques à l'environnement ; ne bifurquez pas l'arbre IaC par environnement.
• Restituez uniquement les valeurs stables, non-secret requises par le déploiement ou la configuration de l'application.
• Utilisez un nommage déterministe et des tags cohérents qui incluent le projet et l'environnement.
• Ajoutez des attributions de rôle aux identités plutôt que de distribuer des clés de service.
• Utilisez des couches d'infrastructure uniquement quand des scopes séparés ou des dépendances de cycle de vie le justifient.

3. Modélisez les environnements

• Utilisez des noms prévisibles tels que <project>-dev pour les environnements partagés et <alias>-dev pour les environnements personnels.
• Utilisez azd env set, azd env unset, et azd env set-secret au lieu de modifier .env directement.
• Utilisez -e ou --environment dans les scripts et l'automatisation pour que la cible soit explicite.
• Utilisez azd env refresh pour synchroniser les outputs de déploiement après qu'un autre acteur modifie un environnement.
• Configurez l'état distant AZD quand une équipe partage l'état d'environnement.

4. Ajoutez des hooks uniquement pour les lacunes de cycle de vie

• Préférez les IaC déclaratifs et la configuration native des services aux hooks.
• Utilisez les hooks racine pour le comportement à l'échelle du projet et les hooks de service pour le comportement spécifique au service.
• Conservez la logique non-triviale des hooks dans les scripts versionnés sous scripts/azd.
• Définissez shell explicitement. Fournissez des variantes windows et posix si nécessaire.
• Rendez les hooks idempotents, non-interactifs en CI, et échouez sur les erreurs sauf si l'échec est intentionnellement sans blocage.
• Testez un hook indépendamment avec azd hooks run <hook-name>.

5. Construisez CI/CD délibérément

• Gardez la définition du pipeline avec le template et examinez les changements générés de azd pipeline config.
• Utilisez des credentials fédérés de courte durée où le fournisseur les supporte.
• Exécutez les tests et la validation IaC avant l'approvisionnement.
• Utilisez des environnements explicites et --no-prompt dans l'automatisation.
• Ajoutez des environnements de production protégés et des portes d'approbation.
• Pour Terraform, configurez l'état distant protégé avant la mise en place du pipeline et tenez compte des limitations actuelles d'authentification AZD.

Validez avant de terminer

Exécutez uniquement les vérifications applicables au repository :

Application: formateur existant, linter, type-check, build, et tests
Bicep:      az bicep build --file infra/main.bicep
Terraform:  terraform fmt -check -recursive
            terraform init -backend=false
            terraform validate
Hooks AZD:  azd hooks run <hook-name>
Packaging:  azd package

Pour un what-if Bicep ou un plan Terraform, choisissez la portée de déploiement et l'environnement corrects. Ces vérifications peuvent s'authentifier à Azure ou lire l'état distant, donc suivez les garde-fous de sécurité.

Vérifiez que :

• Les chemins azure.yaml existent et les paramètres de service correspondent aux projets source.
• Le point d'entrée IaC et le fournisseur s'accordent avec azure.yaml.
• Les outputs de déploiement requis correspondent aux variables consommées par les services, hooks, et pipelines.
• .gitignore exclut .azure, les secrets, l'état local, et les artefacts générés.
• Aucun secret n'apparaît dans le contenu suivi ou la sortie de commande.
• La documentation explique les prérequis, la création d'environnement, le déploiement, la vérification, et le nettoyage.

Rapportez le résultat

Indiquez :

• Les fichiers et comportements modifiés.
• Les hypothèses de fournisseur IaC et d'environnement.
• Les vérifications effectuées.
• Toute commande changeante de cloud délibérément non exécutée.
• Toute fonctionnalité bêta ou preview sur laquelle la solution s'appuie.

Ne prétendez pas au succès du déploiement à moins que l'environnement cible n'ait été réellement déployé et vérifié.