Effectuer une vérification lint et valider votre code Bicep

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 doivent être valides. Et quand les ressources définies dans le fichier sont déployées, elles doivent rester dans les quotas et les limites qui existent 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 meilleure chance de réussir le 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 peut déployer ou modifier uniquement un sous-ensemble 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. Ils vérifient que vous avez utilisé correctement les mots clés du langage Bicep et que vous avez défini vos ressources Azure en fonction des exigences de 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 respecté les meilleures pratiques en matière de maintenabilité, de justesse, de flexibilité et d’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(). 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 l’homme et les utilisateurs peuvent ne pas le modifier avant 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 configurer Bicep pour vérifier votre fichier en créant manuellement le fichier Bicep via l’interface CLI Bicep :

az bicep build --file main.bicep

bicep build main.bicep

Parce que vous voulez que le linter vérifie vos modèles Bicep chaque fois que quelqu’un vérifie du code dans votre référentiel, vous pouvez ajouter une étape et un travail de lint à 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 traceur Bicep ne sont pas traités comme des erreurs, de sorte qu’ils n’interrompent pas l’exécution du pipeline ni les étapes 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. Vous effectuez cette configuration en ajoutant un fichier bicepconfig.json au 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.

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 permet de s’assurer que le code Bicep problématique n’est 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 exécute des vérifications qui ont besoin d’informations à partir d’Azure. 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 pour soumettre un fichier Bicep à la validation préliminaire. Configurez le deploymentMode sur 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éliminaire vérifie si un autre compte de stockage a 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 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.

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.