Lint e valide seu código Bicep

Agora que você já sabe para o que servem as fases do pipeline, vamos considerar o primeiro conjunto de etapas de validação que pode ser adicionado ao pipeline de implantação do Bicep. Nessa unidade, você aprenderá sobre como validar modelos de bíceps. Você também aprenderá sobre as duas atividades que um estágio de validação normalmente executa: linting e validação pré-voo.

O que é um arquivo Bíceps 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 verificações de erros de sintaxe, definições de recursos válidas do Azure e qualidade do código. Essas etapas fazem parte de um processo chamado linting. Para verificar se há outros problemas, você precisa solicitar que o serviço do Azure Resource Manager valide seu modelo e leve seu ambiente do Azure em conta.

Um modelo Bicep válido tem mais chances de implantação bem-sucedida. Você receberá feedback sem precisar implantar seu modelo de bíceps. A validação é uma boa prática, pois se você implantar um arquivo Bicep que não seja válido, o Azure poderá implantar ou alterar apenas um subconjunto dos recursos descritos em seu modelo. Isso pode significar que o estado do ambiente é inconsistente e talvez não se comporte da maneira esperada.

Construir e executar o lint do código Bicep

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

Além disso, o Bicep executa um linter em seus arquivos. Linting é o processo de verificar seu código em relação a um conjunto de recomendações. O linter Bicep examina seu arquivo e verifica se você seguiu as práticas recomendadas de 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 usados. O linter examina os 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 Bíceps.
• Interpolação de cadeia de caracteres. O linter verifica se o arquivo usa a função concat() em vez da interpolação de cadeia de caracteres do Bicep. A interpolação de strings torna os 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 decorador @secure(). Um valor padrão para um parâmetro seguro é uma prática incorreta porque fornece ao parâmetro seguro um valor legível por humanos e as pessoas podem não alterá-lo antes da implantação.

O linter Bicep é executado automaticamente quando você usa a ferramenta Bicep. Toda vez que você cria um arquivo Bicep, o linter o verifica em relação às melhores práticas. O linting ocorre automaticamente quando você implanta um arquivo Bicep no Azure. Mas em um pipeline, normalmente você deseja executar as etapas de validação e linting antes de implantar o arquivo. Você pode configurar o Bicep para verificar seu arquivo compilando manualmente o arquivo Bicep por meio da CLI do Bicep:

az bicep build --file main.bicep

bicep build main.bicep

Como você deseja que o linter verifique seus modelos Bicep sempre que alguém fizer check-in de código no repositório, adicione uma etapa de lint e um trabalho ao pipeline:

Você pode expressar essa adição no arquivo YAML do pipeline como este:

stages:

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

Avisos e erros do linter

Por padrão, o linter emite um aviso quando descobre que um arquivo Bicep violou uma regra. Os avisos emitidos pelo linter Bicep não são tratados como erros, portanto, não interrompem a execução do pipeline nem impedem a execução de estágios subsequentes.

Você pode alterar esse comportamento configurando o Bicep para tratar as violações da regra do linter como erros em vez de avisos. Realize essa configuração adicionando um arquivo bicepconfig.json à pasta que contém o arquivo Bicep. Você pode decidir quais problemas de linter devem ser tratados como erros e quais devem permanecer como avisos. Você verá como atualizar as regras de linter mais adiante neste módulo.

Após reconfigurar o linter para emitir erros, sempre que o linter detectar 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 Bicep problemático não seja implantado.

Validação de simulação

Você também deve verificar se o modelo Bicep provavelmente será implantado no seu ambiente do Azure com êxito. Essa verificação é chamada de validação de pré-vôo e executa verificações que precisam de informações do Azure. Esses tipos de verificações incluem:

• Os nomes que você especificou para os recursos do Bicep são válidos?
• Os nomes que você especificou para os recursos do Bicep já foram usados?
• As regiões em que você está implantando os recursos são válidas?

A validação prévia requer comunicação com o Azure, mas não implanta nenhum recurso.

Você pode usar a tarefa AzureResourceManagerTemplateDeployment para enviar um arquivo Bicep para validação prévia. 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. Ela executa verificações extras nos recursos usados no seu modelo.

Por exemplo, suponha que o arquivo Bicep contenha uma conta de armazenamento. A validação prévia verifica se outra conta de armazenamento já tem o nome escolhido. Também verifica se o nome que você escolheu 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 erros no linter, você os detectará rapidamente, em vez de aguardar a conclusão do processo de validação. A validação leva mais tempo.

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