Lint och verifiera din Bicep-kod

  • 5 minuter

Nu när du vet vilka pipelinesteg som är till för ska vi överväga den första uppsättningen valideringssteg som du kan lägga till i din Bicep-distributionspipeline. I den här lektionen får du lära dig hur du validerar Bicep-mallar. Du får också lära dig om de två aktiviteter som ett valideringssteg vanligtvis utför: linting och preflight-validering.

Vad är en giltig Bicep-fil?

En giltig Bicep-fil är en fil som inte innehåller några syntaxfel. Dessutom är definitionerna för de Azure-resurser som du planerar att distribuera giltiga. Och när de resurser som definierats i filen distribueras håller de sig inom de kvoter och gränser som finns i din Azure-prenumeration.

Vissa av kontrollerna utförs i din Bicep-fil isolerat, till exempel kontroller av syntaxfel, giltiga Azure-resursdefinitioner och kodkvalitet. De här stegen är en del av en process som kallas linting. För att söka efter andra problem måste du begära att Azure Resource Manager-tjänsten validerar mallen och tar hänsyn till Din Azure-miljö.

En giltig Bicep-mall har större chans att distributionen lyckas. Du får feedback utan att distribuera Bicep-mallen. Validering är en bra idé eftersom Azure kan distribuera eller ändra en delmängd av de resurser som beskrivs i mallen om du distribuerar en ogiltig Bicep-fil. Resultatet kan vara att miljöns tillstånd är inkonsekvent och kanske inte fungerar som förväntat.

Skapa och lint Bicep-kod

När du distribuerar en Bicep-fil kör Bicep-verktyget först några grundläggande valideringssteg. De här stegen är samma som körs när du ändrar filen med hjälp av Visual Studio Code. De kontrollerar att du har använt Biceps språknyckelord korrekt och att du har definierat dina Azure-resurser enligt kraven för varje resurstyp.

Dessutom kör Bicep en linter över dina filer. Linting är processen att kontrollera koden mot en uppsättning rekommendationer. Bicep-lintern tittar på din fil och verifierar att du har följt metodtipsen för underhåll, korrekthet, flexibilitet och utökningsbarhet.

En linter innehåller en fördefinierad uppsättning regler för var och en av dessa kategorier. Exempel på linterregler är:

  • Oanvända parametrar: Linter söker efter parametrar som inte används någonstans i Bicep-filen. Genom att eliminera oanvända parametrar gör du det enklare att distribuera mallen eftersom du inte behöver ange onödiga värden. Du kan också minska förvirringen när någon försöker arbeta med din Bicep-fil.
  • Stränginterpolation: Linter kontrollerar om filen använder concat() funktionen i stället för Bicep-stränginterpolation. Stränginterpolation gör dina Bicep-filer mer läsbara.
  • Standardvärden för säkra parametrar: Lintern varnar dig om du anger standardvärden för parametrar som har markerats med dekoratören @secure() . Ett standardvärde för en säker parameter är en felaktig metod eftersom den ger den säkra parametern ett värde som kan läsas av människor och personer kanske inte ändrar den innan de distribuerar den.

Bicep-lintern körs automatiskt när du använder Bicep-verktyget. Varje gång du skapar en Bicep-fil kontrollerar lintern den mot bästa praxis. Lintning sker automatiskt när du distribuerar en Bicep-fil till Azure.

Men i en pipeline vill du vanligtvis köra verifierings- och lintningsstegen innan du distribuerar filen. Du kan be Bicep att verifiera filen genom att manuellt skapa Bicep-filen via Bicep CLI:

az bicep build --file main.bicep

bicep build main.bicep

Kommentar

När du kör build kommandot transpilerar Bicep även din Bicep-kod till en JSON ARM-mall. Du behöver vanligtvis inte den fil som den matar ut, så du kan ignorera den.

Eftersom du vill att linter ska kontrollera dina Bicep-mallar varje gång någon checkar in kod på lagringsplatsen kan du lägga till ett lintsteg och jobb i pipelinen:

Diagram som visar en pipeline med en lint-fas som innehåller ett enda jobb som kör lintern på filen.

Du kan uttrycka det här tillägget i din YAML-pipelinefil så här:

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - script: |
          az bicep build --file deploy/main.bicep

Linter-varningar och -fel

Som standard genererar lintern en varning när den upptäcker att en Bicep-fil har brutit mot en regel. Varningar om att Bicep-lintern genererar behandlas inte som ett fel, så de stoppar inte pipelinekörningen eller stoppar efterföljande steg från att köras.

Du kan ändra det här beteendet genom att konfigurera Bicep för att behandla överträdelser av linterregeln som fel i stället för varningar. Du gör den här konfigurationen genom att lägga till en bicepconfig.json fil i mappen som innehåller din Bicep-fil. Du kan bestämma vilka linterproblem som ska behandlas som fel och vilka som ska förbli som varningar. Du ser hur du uppdaterar linterregler senare i den här modulen.

Dricks

Filen bicepconfig.json styr också hur Visual Studio Code visar fel och varningar i redigeraren. Den visar röda och gula vågiga linjer under felkonfigurerade delar i Bicep-mallen. Dessa indikatorer ger dig ännu snabbare feedback när du skriver din Bicep-kod, vilket ytterligare minskar risken för ett fel.

När du har konfigurerat om lintern för att generera fel slutar pipelinen att köras och efterföljande jobb eller faser inte körs när lintern upptäcker ett problem. Den här konfigurationen hjälper till att säkerställa att problematisk Bicep-kod inte distribueras.

Preflight-validering

Du bör också kontrollera om din Bicep-mall sannolikt kommer att distribueras till Din Azure-miljö. Den här kontrollen kallas för preflight-validering och kör fler kontroller som behöver Azure för att tillhandahålla information. Den här typen av kontroller omfattar:

  • Är de namn som du har angett för dina Bicep-resurser giltiga?
  • Har de namn som du har angett för dina Bicep-resurser redan tagits?
  • Är de regioner som du distribuerar dina resurser till giltiga?

Preflight-validering kräver kommunikation med Azure, men det distribuerar inga resurser.

Diagram som visar en pipeline med lint- och valideringssteg som var och en innehåller ett enda jobb. Verifieringssteget kommunicerar med Azure.

Du kan använda uppgiften AzureResourceManagerTemplateDeployment för att skicka en Bicep-fil för preflight-validering och konfigurera deploymentMode till Validation:

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

Det här kommandot liknar den distributionsuppgift som du redan har använt, men det distribuerar inga resurser. Den utför extra kontroller mot de resurser som används i mallen.

Anta till exempel att din Bicep-fil innehåller ett lagringskonto. Preflight-valideringen kontrollerar om ett annat lagringskonto redan har tagit det namn som du har valt. Den kontrollerar också om namnet du valde för lagringskontot uppfyller namngivningskonventionerna.

Valideringskommandot preflight kör även Bicep-lintern. Det är dock vanligtvis en bra idé att köra linter separat. På så sätt, om det finns några linterfel, identifierar du dem snabbt i stället för att vänta på att valideringsprocessen ska slutföras. Verifieringen tar längre tid.

Viktigt!

När du kör en förhandsvalidering utför var och en av Azure-resursprovidrar sina egna kontroller. Vissa resursprovidrar kör inte många kontroller, medan andra gör det, så du kan inte förlita dig på förhandsverifiering för att vara säker på att filen är giltig. Ändå är det ett användbart verktyg och är värt att inkludera i din pipeline.

Genom att lägga till valideringssteg i pipelinen för att köra linter och utföra en preflight-validering får du större förtroende innan du distribuerar Bicep-filen.