Lint e valide o seu código Bicep

Agora que você sabe para que servem os estágios do pipeline, vamos considerar o primeiro conjunto de etapas de validação que você pode adicionar ao seu pipeline 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 que um estágio de validação normalmente realiza: forro e validação de comprovação.

O que é um arquivo Bicep válido?

Um arquivo Bicep válido é aquele que não contém erros de sintaxe. Além disso, as definições para os recursos do Azure que você planeja implantar devem ser válidas. E quando os recursos definidos no arquivo são implantados, eles devem permanecer 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 em conta seu ambiente do Azure.

Um modelo Bicep válido tem mais chances de implantação bem-sucedida. Você receberá feedback sem 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. O resultado pode ser que o estado do seu ambiente é inconsistente e pode não se comportar da maneira esperada.

Construir e lint código Bicep

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 palavras-chave de idioma 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 Bicep analisa 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-te se definires valores padrão para parâmetros que são assinalados com o decorador @secure(). Um valor padrão para um parâmetro seguro é uma prática incorreta porque dá ao parâmetro seguro um valor legível por humanos, e as pessoas podem não alterá-lo antes da implantação.

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. O Linting acontece automaticamente quando você implanta um arquivo Bicep no Azure. Mas, em um pipeline, você normalmente deseja executar as etapas de validação e forro antes de implantar o arquivo. Você pode configurar o 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

Como você deseja que o linter verifique seus modelos do Bicep sempre que alguém verificar o código em seu repositório, você pode adicionar um estágio e um trabalho de fiapos ao seu pipeline:

Você pode expressar essa adição em seu arquivo YAML de pipeline assim:

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - 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 violou uma regra. Os avisos que o linter do Bicep emite não são tratados como erros, por isso não interromperão a execução do pipeline nem a execução de estágios 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ê verá como atualizar as regras linter mais adiante neste módulo.

Depois de reconfigurar o linter para emitir erros, sempre que o linter detetar um problema, o pipeline para de ser executado e os trabalhos ou estágios subsequentes não são executados. Essa configuração ajuda a garantir que o código problemático do Bicep 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. Essa verificação é chamada validação de pré-verificação, e executa verificações que precisam de informações do Azure. 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.

Pode utilizar a tarefa AzureResourceManagerTemplateDeployment para enviar um arquivo Bicep para validação preliminar. Configure o deploymentMode para Validation:

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

Esse comando é semelhante à tarefa de implantação que você já usou, mas na verdade não implanta nenhum recurso. Ele executa verificações extras em relação aos recursos usados em seu modelo.

Por exemplo, suponha que seu arquivo Bicep contenha uma conta de armazenamento. A validação prévia verifica se outra conta de armazenamento já possui o nome que escolheu. 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 prévia 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.

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