Lint e valide o seu código Bicep

Concluído

Agora que você sabe para que servem os trabalhos de fluxo de trabalho, vamos considerar o primeiro conjunto de etapas de validação que você pode adicionar ao seu fluxo de trabalho de implantação do Bicep. Nesta unidade, você aprenderá sobre a validação de modelos do Bicep. Você também aprenderá sobre as duas atividades de validação que são comumente usadas: linting e validação de comprovação.

O que é um arquivo Bicep válido?

Um arquivo Bicep válido não contém erros de sintaxe. Além disso, as definições para os recursos do Azure que você planeja implantar são válidas. E quando os recursos definidos no arquivo são implantados, eles permanecem dentro das cotas e limites existentes em sua assinatura do Azure.

Algumas das verificações são executadas no arquivo Bicep isoladamente, como as verificações de erros de sintaxe, definições de recursos válidas do Azure e qualidade do código. Estas etapas fazem parte de um processo chamado linting. Para verificar outros problemas, você precisa solicitar que o serviço Azure Resource Manager valide seu modelo e leve seu ambiente do Azure em consideração.

Um modelo Bicep válido tem uma maior chance de implantação bem-sucedida. Você recebe feedback sem realmente implantar seu modelo Bicep. A validação é uma boa prática porque, se você implantar um arquivo Bicep que não é válido, o Azure poderá implantar ou alterar apenas um subconjunto dos recursos descritos em seu modelo. Uma implantação parcial pode significar que o estado do seu ambiente é inconsistente e pode não se comportar da maneira esperada.

Código Bicep de construção e revestimento

Quando você implanta um arquivo Bicep, as ferramentas do Bicep primeiro executam algumas etapas básicas de validação. Essas etapas são as mesmas que são executadas quando você modifica seu arquivo usando o Visual Studio Code. Eles verificam se você usou as palavras-chave de idioma do Bicep corretamente e se definiu seus recursos do Azure de acordo com os requisitos para cada tipo de recurso.

Além disso, o Bicep executa um linter sobre os seus ficheiros. Linting é o processo de verificar o seu código em relação a um conjunto de recomendações. O linter do Bíceps examina seu arquivo e verifica se você seguiu as práticas recomendadas para manutenção, correção, flexibilidade e extensibilidade.

Um linter contém um conjunto predefinido de regras para cada uma dessas categorias. Exemplos de regras de linter incluem:

• Parâmetros não utilizados. O linter verifica quaisquer parâmetros que não são usados em nenhum lugar no arquivo Bicep. Ao eliminar parâmetros não utilizados, você facilita a implantação do modelo porque não precisa fornecer valores desnecessários. Você também reduz a confusão quando alguém tenta trabalhar com seu arquivo Bicep.
• Interpolação de cordas. O linter verifica se o arquivo usa a concat() função em vez da interpolação de cadeia de caracteres do Bícep. A interpolação de cadeias de caracteres torna seus arquivos Bicep mais legíveis.
• Valores padrão para parâmetros seguros. O linter avisa se você definir valores padrão para parâmetros marcados com o @secure() decorador. Definir padrões para parâmetros seguros é uma prática ruim porque dá ao parâmetro seguro um valor legível por humanos, e as pessoas podem não alterá-lo antes de implantá-lo.

O linter do Bíceps é executado automaticamente quando você usa as ferramentas do Bíceps. Toda vez que você cria um arquivo Bicep, o linter o verifica em relação às suas práticas recomendadas. Essa verificação acontece automaticamente quando você implanta um arquivo Bicep no Azure.

Em um fluxo de trabalho, no entanto, você normalmente deseja executar as etapas de validação e forro antes de implantar o arquivo. Você pode dizer ao Bicep para verificar seu arquivo criando manualmente o arquivo Bicep através da CLI do Bicep:

az bicep build --file main.bicep

bicep build main.bicep

Nota

Quando você executa o comando, o build Bicep também transpila seu código Bicep para um modelo JSON ARM. Você geralmente não precisa do arquivo que ele produz, então você pode ignorá-lo.

Como você deseja que seus modelos do Bicep sejam alinhados sempre que alguém fizer check-in de código em seu repositório, você pode adicionar um trabalho lint ao seu fluxo de trabalho:

Você expressa essa adição em seu arquivo YAML de fluxo de trabalho assim:

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

Avisos e erros de Linter

Por padrão, o linter emite um aviso quando descobre que um arquivo Bicep viola uma regra. Os avisos que o linter do Bicep emite não são tratados como erros, portanto, não interrompem a execução do fluxo de trabalho ou interrompem a execução de trabalhos subsequentes.

Você pode alterar esse comportamento configurando o Bicep para tratar as violações da regra linter como erros em vez de avisos. Para fazer essa configuração, adicione um arquivo bicepconfig.json à pasta que contém o arquivo Bicep. Você pode decidir quais questões linter devem ser tratadas como erros e quais devem permanecer como avisos. Você configurará o linter mais tarde neste módulo.

Gorjeta

O arquivo bicepconfig.json também controla como o Visual Studio Code mostra erros e avisos no editor. Ele exibe linhas onduladas vermelhas e amarelas sob partes mal configuradas no seu modelo Bicep. Esses indicadores fornecem feedback ainda mais rápido quando você está escrevendo seu código Bicep, reduzindo ainda mais a chance de erro.

Depois de reconfigurar o linter para emitir erros, sempre que o linter detetar um problema, o fluxo de trabalho para de ser executado e os trabalhos subsequentes não são executados. Essa configuração ajuda a garantir que o código Bicep problemático não seja implantado.

Validação de comprovação

Você também deve verificar se é provável que seu modelo Bicep seja implantado em seu ambiente do Azure com êxito. Esse processo é chamado de validação de comprovação e executa verificações que precisam do Azure para fornecer informações. Estes tipos de controlo incluem:

• Os nomes que você especificou para seus recursos do Bicep são válidos?
• Os nomes que você especificou para seus recursos do Bíceps já foram usados?
• As regiões para as quais você está implantando seus recursos são válidas?

A validação de comprovação requer comunicação com o Azure, mas na verdade não implanta nenhum recurso.

Para enviar um arquivo Bicep para validação de comprovação, use a arm-deploy ação e defina como deploymentMode 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

Você também pode usar o comando da CLI do az deployment group validate Azure.

A validação de comprovação é semelhante a uma implantação normal, mas na verdade não implanta nenhum recurso. Ele executa verificações extras em relação aos recursos que estão sendo usados em seu modelo.

Por exemplo, suponha que seu arquivo Bicep contenha uma conta de armazenamento. A validação de comprovação verifica se outra conta de armazenamento já adotou o nome escolhido. Ele também verifica se o nome escolhido para a conta de armazenamento está em conformidade com as convenções de nomenclatura.

O comando de validação de comprovação também executa o linter Bicep. No entanto, geralmente é uma boa ideia executar o linter separadamente. Dessa forma, se houver algum erro de linter, você os detetará rapidamente, em vez de esperar que o processo de validação termine. A validação demora mais tempo.

Importante

Quando você executa uma validação de comprovação, cada um dos provedores de recursos do Azure executa suas próprias verificações. Alguns provedores de recursos não executam muitas verificações, enquanto outros executam. Portanto, você não pode confiar na validação de comprovação para ter certeza de que seu arquivo é válido. No entanto, é uma ferramenta útil e vale a pena incluir no seu fluxo de trabalho.

Ao adicionar trabalhos de validação ao seu fluxo de trabalho para executar o linter e executar uma validação de comprovação, você terá mais confiança antes de implantar seu arquivo Bicep.