Effectuer une vérification lint et valider votre code Bicep

Effectué

Maintenant que vous connaissez les objectifs des phases des pipelines, examinons le premier ensemble d’étapes de validation que vous pouvez ajouter à votre pipeline 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 courantes dans une phase de validation : le linting et la validation préalable.

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

Un fichier Bicep valide est un fichier qui 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 un déploiement. Vous obtenez un feedback sans déployer votre modèle Bicep. La validation est une bonne pratique, car si vous déployez un fichier Bicep non valide, Azure risque de déployer ou de modifier seulement une partie des ressources décrites dans votre modèle. Le résultat peut être que l’état de votre environnement est incohérent et ne pas se comporter comme prévu.

Générer et vérifier (lint) 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. Elles vérifient que vous avez utilisé correctement les mots clés du langage Bicep et que 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 bonnes 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 les paramètres marqués avec le décorateur @secure(). Une valeur par défaut pour un paramètre sécurisé est une mauvaise pratique, car elle donne au paramètre sécurisé une valeur lisible par les humains, et il est possible que des personnes ne la changent pas 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. Le linting se produit automatiquement quand vous déployez un fichier Bicep sur Azure.

Cependant, dans un pipeline, 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 le linter vérifie vos modèles Bicep chaque fois que quelqu’un archive du code dans votre dépôt, vous pouvez ajouter une phase et un travail de linting à votre pipeline :

Vous pouvez exprimer cet ajout dans votre fichier YAML de pipeline comme ceci :

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - 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 ne respecte pas 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 pipeline ni celle des phases 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 verrez comment mettre à jour les règles du 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 pipeline cesse de s’exécuter et les travaux ou les phases ultérieurs ne sont pas exécutés. Cette configuration garantit 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. Cette vérification est appelée validation préliminaire et elle effectue plus de vérifications qui nécessitent qu’Azure fournisse 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.

Vous pouvez utiliser la tâche AzureResourceManagerTemplateDeployment afin de soumettre un fichier Bicep pour validation préliminaire et configurer deploymentMode avec Validation :

- stage: Validate
  jobs:
  - job: Validate
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        inputs:
          connectedServiceName: 'MyServiceConnection'
          location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep

Cette commande est similaire à la tâche de déploiement que vous avez déjà utilisée, mais elle ne déploie pas réellement de ressources. Elle effectue des vérifications supplémentaires sur les ressources utilisées dans votre modèle.

Par exemple, supposons que votre fichier Bicep contient un compte de stockage. La validation préalable vérifie si un autre compte de stockage utilise déjà 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. Certains fournisseurs de ressources n’exécutent pas beaucoup de vérifications, contrairement à d’autres. Vous ne pouvez donc pas vous fier à la validation préliminaire pour être certain que votre fichier est valide. Néanmoins, c’est un outil pratique et cela vaut la peine de l’inclure dans votre pipeline.

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