Como pré-visualizar alterações do Bicep com what-if

O comando what-if da Azure CLI mostra que recursos um ficheiro Bicep vai criar, alterar ou remover, antes de aplicares seja o que for. Funciona como uma pré-visualização — um diff da tua infraestrutura — e é a forma mais simples de evitar surpresas em produção. O melhor é que não muda nada: é uma operação segura, só de leitura. Aqui vais usar o what-if com um Storage Account de exemplo e aprender a ler o resultado.

Pré-requisitos

• Uma subscrição Azure ativa com permissões para criar recursos.
• A Azure CLI instalada e sessão iniciada com az login.
• Um resource group para testar, por exemplo rg-demo.
• Um editor de texto (o VS Code com a extensão Bicep ajuda, mas não é obrigatório).

Passo 1: Criar um ficheiro Bicep simples

Cria um ficheiro chamado main.bicep que declara um Storage Account. É este o recurso que o what-if vai analisar:

param location string = resourceGroup().location
param storageName string

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

O nome de um Storage Account tem de ser único a nível global: só letras minúsculas e números, entre 3 e 24 caracteres.

Passo 2: Garantir que o resource group existe

O what-if precisa de um âmbito contra o qual comparar. Se ainda não tens onde testar, cria o resource group:

az group create --name rg-demo --location westeurope

Passo 3: Correr o what-if

Agora pede à Azure CLI para calcular a diferença entre o teu ficheiro e o que já existe no resource group. Como o Storage Account ainda não existe, o resultado deve ser uma criação:

az deployment group what-if --resource-group rg-demo --template-file main.bicep --parameters storageName=stbconceptsdemo01

O what-if envia o teu template para a Azure, que o compara com o estado atual e devolve apenas as diferenças. Nenhum recurso é alterado nesta fase. Substitui stbconceptsdemo01 por um nome livre que respeite as regras do Passo 1.

Passo 4: Ler o resultado

O what-if apresenta cada recurso com um símbolo e uma cor à frente. Estes são os que vais encontrar com mais frequência:

• + Create: o recurso vai ser criado.
• ~ Modify: o recurso já existe e vai mudar; a saída mostra propriedade a propriedade.
• - Delete: o recurso vai ser removido.
• = NoChange: fica exatamente igual.
• ! Ignore: está fora do âmbito e não é tocado.

Nesta primeira execução deves ver uma linha começada por + com o caminho Microsoft.Storage/storageAccounts/stbconceptsdemo01, sinal de que a criação está pronta a avançar.

Passo 5: Provocar um Modify

Para veres o what-if a detetar uma mudança, faz primeiro o deploy real e só depois altera o ficheiro. Aplica o Bicep:

az deployment group create --resource-group rg-demo --template-file main.bicep --parameters storageName=stbconceptsdemo01

Abre o main.bicep e troca o SKU de Standard_LRS para Standard_GRS. Corre outra vez o comando do Passo 3: em vez de Create, deves ver agora ~ Modify, com a linha do sku.name a passar de um valor para o outro.

Verificar o resultado

Sabes que está a funcionar quando o resumo final do what-if reflete a tua intenção. A CLI termina com uma contagem do tipo Resource changes: 1 to create na primeira corrida e 1 to modify depois de mexeres no SKU. Se vires 0 to create, 0 to modify quando esperavas mudanças, confirma que estás a apontar para o resource group certo e que guardaste o ficheiro.

Conclusão

Com o what-if passas a ter uma pré-visualização fiável de cada deploy Bicep, o que reduz muito o risco de criar, alterar ou apagar algo sem querer. O passo seguinte natural é colocar este comando nos teus pipelines de CI/CD, para que cada Pull Request mostre o impacto na infraestrutura antes da aprovação. Uma dica para o dia a dia: usa az deployment group create --confirm-with-what-if para ver o diff e confirmar o deploy no mesmo comando. Em que ponto do teu fluxo de trabalho é que esta pré-visualização te daria mais tranquilidade?