Effectuer une vérification lint et valider votre code Bicep

  • 5 minutes

Maintenant que vous connaissez les objectifs des travaux de workflow, examinons le premier ensemble d’étapes de validation que vous pouvez ajouter à votre workflow de déploiement Bicep. Dans cette unité, vous allez découvrir comment valider des modèles Bicep. Vous découvrirez également les deux activités de validation couramment utilisées : le linting et la validation préalable.

Qu’est-ce qu’un fichier Bicep valide ?

Un fichier Bicep valide ne contient aucune erreur de syntaxe. En outre, les définitions des ressources Azure que vous envisagez de déployer sont valides. Quand les ressources définies dans le fichier sont déployées, elles restent dans les quotas et les limites applicables dans votre abonnement Azure.

Certaines des vérifications sont effectuées sur votre fichier Bicep de façon isolée, comme la recherche d’erreurs de syntaxe, et les contrôles de validité des définitions des ressources Azure et de la qualité du code. Ces étapes font partie d’un processus appelé linting. Pour rechercher d’autres problèmes, vous devez demander que le service Azure Resource Manager valide votre modèle et prenne en compte votre environnement Azure.

Un modèle Bicep valide a une plus grande chance de réussir le déploiement. Vous obtenez un feedback sans déployer réellement votre modèle Bicep. La validation est une bonne pratique, car si vous déployez un fichier Bicep qui n’est pas valide, Azure risque de déployer ou modifier seulement une partie des ressources décrites dans votre modèle. Un déploiement partiel peut signifier que l’état de votre environnement est incohérent et qu’il risque de ne pas se comporter comme prévu.

Génération et linting du code Bicep

Quand vous déployez un fichier Bicep, les outils Bicep exécutent d’abord certaines étapes de validation de base. Ces étapes sont identiques à celles qui sont effectuées quand vous modifiez votre fichier en utilisant Visual Studio Code. Une vérification est effectuée afin de contrôler si vous avez utilisé correctement les mots clés du langage Bicep et si vous avez défini vos ressources Azure conformément aux exigences pour chaque type de ressource.

En outre, Bicep exécute un linter sur vos fichiers. Le linting est le processus de vérification de votre code par rapport à un ensemble de recommandations. Le linter Bicep examine votre fichier et vérifie que vous avez suivi les meilleures pratiques pour la maintenabilité, la conformité, la flexibilité et l’extensibilité.

Un linter contient un ensemble prédéfini de règles pour chacune de ces catégories. Voici des exemples de règles de linter :

  • Paramètres inutilisés. Le linter recherche les paramètres qui ne sont utilisés nulle part dans le fichier Bicep. En éliminant les paramètres inutilisés, vous facilitez le déploiement de votre modèle, car vous n’avez pas besoin de fournir des valeurs non nécessaires. Vous réduisez également les risques de confusion quand quelqu’un essaie de travailler avec votre fichier Bicep.
  • Interpolation de chaîne. Le linter vérifie si votre fichier utilise la fonction concat() au lieu de l’interpolation de chaîne Bicep. L’interpolation de chaîne rend vos fichiers Bicep plus lisibles.
  • Valeurs par défaut pour les paramètres sécurisés. Le linter vous avertit si vous définissez des valeurs par défaut pour des paramètres marqués avec le décorateur @secure(). La définition des valeurs par défaut pour les paramètres sécurisés est une mauvaise pratique, car elle leur donne une valeur que tout le monde peut lire et que personne risque de changer avant d’effectuer le déploiement.

Le linter Bicep s’exécute automatiquement quand vous utilisez les outils Bicep. Chaque fois que vous générez un fichier Bicep, le linter le vérifie par rapport aux bonnes pratiques. Cette vérification a lieu automatiquement quand vous déployez un fichier Bicep sur Azure.

Cependant, dans un flux de travail, vous voulez en général exécuter les étapes de validation et de linting avant de déployer le fichier. Vous pouvez demander à Bicep de vérifier votre fichier en créant manuellement le fichier Bicep par le biais de l’interface CLI de Bicep :

az bicep build --file main.bicep

bicep build main.bicep

Notes

Quand vous exécutez la commande build, Bicep transpile également votre code Bicep en un modèle ARM JSON. En général, vous n’avez pas besoin du fichier qu’il génère : vous pouvez donc l’ignorer.

Comme vous voulez que vos modèles Bicep fassent l’objet d’un linting chaque fois que quelqu’un archive du code dans votre dépôt, vous pouvez ajouter un travail lint à votre workflow :

Diagramme montrant un workflow avec un seul travail lint qui exécute le linter sur le fichier.

Vous exprimez cet ajout dans votre fichier YAML de workflow comme ceci :

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - script: |
        az bicep build --file deploy/main.bicep

Erreurs et avertissements du linter

Par défaut, le linter émet un avertissement quand il découvre qu’un fichier Bicep enfreint une règle. Les avertissements émis par le linter Bicep ne sont pas traités comme des erreurs : ils n’arrêtent donc pas l’exécution du flux de travail ni celle des tâches suivantes.

Vous pouvez changer ce comportement en configurant Bicep pour traiter les violations de règle du linter comme des erreurs et non pas comme des avertissements. Pour cette configuration, vous devez ajouter un fichier bicepconfig.json dans le dossier qui contient votre fichier Bicep. Vous pouvez décider quels problèmes du linter doivent être traités comme des erreurs et ceux qui doivent rester des avertissements. Vous configurerez le linter plus loin dans ce module.

Conseil

Le fichier bicepconfig.json contrôle également la manière dont Visual Studio Code affiche les erreurs et les avertissements dans l’éditeur. Il affiche des lignes ondulées rouges et jaunes sous les parties mal configurées de votre modèle Bicep. Ces indicateurs vous donnent un feedback encore plus rapide quand vous écrivez votre code Bicep, ce qui réduit encore davantage les risques d’erreur.

Une fois que vous avez reconfiguré le linter pour l’émission des erreurs, dès que le linter détecte un problème, votre workflow cesse de s’exécuter et les travaux ultérieurs ne sont pas exécutés. Cette configuration permet de garantir que le code Bicep problématique ne sera pas déployé.

Validation préliminaire

Vous devez aussi vérifier que votre modèle Bicep est susceptible d’être déployé correctement dans votre environnement Azure. Ce processus est appelé validation préliminaire et il procède à des vérifications qui demandent à Azure de fournir des informations. Ces types de vérifications sont les suivants :

  • Les noms que vous avez spécifiés pour vos ressources Bicep sont-ils valides ?
  • Les noms que vous avez spécifiés pour vos ressources Bicep sont-ils déjà utilisés ?
  • Les régions où vous déployez vos ressources sont-elles valides ?

La validation préliminaire nécessité une communication avec Azure, mais elle ne déploie réellement aucune ressource.

Diagramme montrant un flux de travail avec des tâches lint et de validation, chacune contenant une seule tâche. La tâche validée communique avec Azure.

Pour soumettre un fichier Bicep à la validation préalable, vous utilisez l’action arm-deploy et vous définissez deploymentMode sur Validate :

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      name: Run preflight validation
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        deploymentMode: Validate

Vous pouvez aussi utiliser la commande az deployment group validate dans Azure CLI.

La validation préalable est similaire à un déploiement normal, mais elle ne déploie aucune ressource réellement. Elle effectue des vérifications supplémentaires sur les ressources qui sont utilisées dans votre modèle.

Par exemple, supposons que votre fichier Bicep contient un compte de stockage. La validation préliminaire vérifie si un autre compte de stockage a déjà pris le nom que vous avez choisi. Elle vérifie aussi si le nom que vous avez choisi pour le compte de stockage est conforme aux conventions de nommage applicables.

La commande de validation préliminaire exécute également le linter Bicep. Il est cependant en général judicieux d’exécuter le linter séparément. Ainsi, si le linter émet des erreurs, vous les détectez rapidement au lieu d’attendre la fin du processus de validation. La validation prend plus de temps.

Important

Quand vous effectuez une validation préalable, chacun des fournisseurs de ressources Azure fait ses propres vérifications. Les vérifications réalisées sont plus ou moins nombreuses en fonction des fournisseurs de ressources. Vous ne pouvez donc pas vous fier à la validation préalable pour être certain que votre fichier est valide. Néanmoins, c’est un outil pratique qui mérite d’être ajouté à votre workflow.

En ajoutant des travaux de validation à votre workflow pour exécuter le linter et effectuer une validation préalable, vous êtes plus confiant avant de déployer votre fichier Bicep.