Lint en valideer uw Bicep-code

Voltooid

Nu u weet wat de pijplijnfasen zijn, gaan we kijken naar de eerste set validatiestappen die u kunt toevoegen aan uw Bicep-implementatiepijplijn. In deze les leert u meer over het valideren van Bicep-sjablonen. U krijgt ook informatie over de twee activiteiten die een validatiefase doorgaans uitvoert: linting en preflight-validatie.

Wat is een geldig Bicep-bestand?

Een geldig Bicep-bestand is een bestand dat geen syntaxisfouten bevat. De definities voor de Azure-resources die u wilt implementeren, zijn ook geldig. En wanneer de resources die in het bestand zijn gedefinieerd, worden geïmplementeerd, blijven ze binnen de quota en limieten die aanwezig zijn in uw Azure-abonnement.

Sommige controles worden geïsoleerd uitgevoerd op uw Bicep-bestand, zoals de controles op syntaxisfouten, voor geldige Azure-resourcedefinities en voor codekwaliteit. Deze stappen maken deel uit van een proces dat linting wordt genoemd. Als u op andere problemen wilt controleren, moet u aanvragen dat de Azure Resource Manager-service uw sjabloon valideert en rekening houdt met uw Azure-omgeving.

Een geldige Bicep-sjabloon heeft een grotere kans op een succesvolle implementatie. U ontvangt feedback zonder uw Bicep-sjabloon te implementeren. Validatie is een goede gewoonte omdat als u een ongeldig Bicep-bestand implementeert, Azure slechts een subset van de resources implementeert of wijzigt die in uw sjabloon worden beschreven. Het resultaat kan zijn dat de status van uw omgeving inconsistent is en zich mogelijk niet gedraagt zoals u verwacht.

Bicep-code bouwen en linten

Wanneer u een Bicep-bestand implementeert, voert de Bicep-hulpprogramma's eerst enkele basisvalidatiestappen uit. Deze stappen zijn dezelfde stappen die worden uitgevoerd wanneer u het bestand wijzigt met behulp van Visual Studio Code. Ze controleren of u bicep's taaltrefwoorden correct hebt gebruikt en of u uw Azure-resources hebt gedefinieerd volgens de vereisten voor elk resourcetype.

Daarnaast voert Bicep een linter uit op uw bestanden. Linting is het proces van het controleren van uw code op basis van een reeks aanbevelingen. De Bicep linter kijkt naar uw bestand en controleert of u de aanbevolen procedures voor onderhoud, juistheid, flexibiliteit en uitbreidbaarheid hebt gevolgd.

Een linter bevat een vooraf gedefinieerde set regels voor elk van deze categorieën. Voorbeelden van linterregels zijn:

• Ongebruikte parameters: De linter scant op parameters die nergens in het Bicep-bestand worden gebruikt. Door ongebruikte parameters te elimineren, kunt u de sjabloon eenvoudiger implementeren omdat u geen onnodige waarden hoeft op te geven. U vermindert ook verwarring wanneer iemand probeert met uw Bicep-bestand te werken.
• Tekenreeksinterpolatie: de linter controleert of uw bestand gebruikmaakt van de concat() functie in plaats van bicep-tekenreeksinterpolatie. Tekenreeksinterpolatie maakt uw Bicep-bestanden beter leesbaar.
• Standaardwaarden voor beveiligde parameters: De linter waarschuwt u als u standaardwaarden instelt voor parameters die zijn gemarkeerd met de @secure() decorator. Een standaardwaarde voor een beveiligde parameter is een slechte gewoonte omdat deze de beveiligde parameter een door mensen leesbare waarde geeft en personen deze mogelijk niet wijzigen voordat ze worden geïmplementeerd.

De Bicep linter wordt automatisch uitgevoerd wanneer u de Bicep-tooling gebruikt. Telkens wanneer u een Bicep-bestand maakt, controleert de linter het op basis van de aanbevolen procedures. Linting gebeurt automatisch wanneer u een Bicep-bestand implementeert in Azure.

Maar in een pijplijn wilt u doorgaans de validatie- en lintingstappen uitvoeren voordat u het bestand implementeert. U kunt Bicep vertellen uw bestand te verifiëren door het Bicep-bestand handmatig te bouwen via de Bicep CLI:

az bicep build --file main.bicep

bicep build main.bicep

Notitie

Wanneer u de build opdracht uitvoert, transpileert Bicep uw Bicep-code ook naar een JSON ARM-sjabloon. Over het algemeen hebt u het bestand dat wordt uitgevoerd niet nodig, zodat u het kunt negeren.

Omdat u wilt dat de linter uw Bicep-sjablonen telkens controleert wanneer iemand code incheckt in uw opslagplaats, kunt u een lintfase en taak toevoegen aan uw pijplijn:

U kunt deze toevoeging als volgt uitdrukken in uw YAML-pijplijnbestand:

stages:

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

Linter-waarschuwingen en -fouten

Standaard verzendt de linter een waarschuwing wanneer wordt gedetecteerd dat een Bicep-bestand een regel heeft geschonden. Waarschuwingen die door de Bicep linter worden verzonden, worden niet behandeld als een fout, zodat de pijplijnuitvoering niet wordt gestopt of dat de volgende fasen niet meer worden uitgevoerd.

U kunt dit gedrag wijzigen door Bicep te configureren om schendingen van linter-regels te behandelen als fouten in plaats van waarschuwingen. U doet deze configuratie door een bicepconfig.json bestand toe te voegen aan de map die uw Bicep-bestand bevat. U kunt bepalen welke linter-problemen moeten worden behandeld als fouten en welke als waarschuwingen moeten blijven. Verderop in deze module ziet u hoe u linterregels bijwerkt.

Tip

Het bestand bicepconfig.json bepaalt ook hoe Visual Studio Code fouten en waarschuwingen in de editor weergeeft. Er worden rode en gele golvende lijnen weergegeven onder onjuist geconfigureerde onderdelen in uw Bicep-sjabloon. Deze indicatoren geven u nog sneller feedback wanneer u uw Bicep-code schrijft, waardoor de kans op een fout verder wordt verkleind.

Nadat u de linter opnieuw hebt geconfigureerd om fouten te verzenden, wordt uw pijplijn niet meer uitgevoerd wanneer de linter een probleem detecteert en worden volgende taken of fasen niet uitgevoerd. Deze installatie helpt ervoor te zorgen dat problematische Bicep-code niet wordt geïmplementeerd.

Preflight-validatie

U moet ook controleren of uw Bicep-sjabloon waarschijnlijk in uw Azure-omgeving wordt geïmplementeerd. Deze controle wordt preflight-validatie genoemd en er worden meer controles uitgevoerd die Azure nodig hebben om informatie op te geven. Dit soort controles zijn onder andere:

• Zijn de namen die u hebt opgegeven voor uw Bicep-resources geldig?
• Zijn de namen die u al hebt opgegeven voor uw Bicep-resources?
• Zijn de regio's die u uw resources implementeert in geldige regio's?

Voor de preflight-validatie is communicatie met Azure vereist, maar er worden geen resources geïmplementeerd.

U kunt de AzureResourceManagerTemplateDeployment taak gebruiken om een Bicep-bestand in te dienen voor de preflight-validatie en het deploymentMode volgende te Validationconfigureren:

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

Deze opdracht is vergelijkbaar met de implementatietaak die u al hebt gebruikt, maar er worden geen resources geïmplementeerd. Er worden extra controles uitgevoerd op de resources die in uw sjabloon worden gebruikt.

Stel dat uw Bicep-bestand een opslagaccount bevat. Tijdens de voorbereidende validatie wordt gecontroleerd of een ander opslagaccount al de naam heeft gebruikt die u hebt gekozen. Ook wordt gecontroleerd of de naam die u voor het opslagaccount hebt gekozen, voldoet aan naamconventies.

Met de preflight-validatieopdracht wordt ook de Bicep linter uitgevoerd. Het is echter meestal een goed idee om de linter afzonderlijk uit te voeren. Als er linterfouten zijn, detecteert u deze snel in plaats van te wachten tot het validatieproces is voltooid. Validatie duurt langer.

Belangrijk

Wanneer u een voorbereidende validatie uitvoert, voert elk van de Azure-resourceproviders zijn eigen controles uit. Sommige resourceproviders voeren niet veel controles uit, terwijl andere wel, zodat u niet kunt vertrouwen op preflight-validatie om er zeker van te zijn dat uw bestand geldig is. Het is echter een nuttig hulpmiddel en is het waard om in uw pijplijn op te slaan.

Door validatiefasen toe te voegen aan uw pijplijn om de linter uit te voeren en een preflight-validatie uit te voeren, hebt u meer vertrouwen voordat u uw Bicep-bestand implementeert.