Cómo previsualizar cambios de Bicep con what-if

El comando what-if de la Azure CLI muestra qué recursos va a crear, cambiar o eliminar un archivo Bicep, antes de que apliques nada. Funciona como una vista previa — un diff de tu infraestructura — y es la forma más sencilla de evitar sorpresas en producción. Lo mejor es que no cambia nada: es una operación segura, de solo lectura. Aquí vas a usar what-if con un Storage Account de ejemplo y aprenderás a leer el resultado.

Requisitos previos

• Una suscripción de Azure activa con permisos para crear recursos.
• La Azure CLI instalada y con sesión iniciada mediante az login.
• Un resource group para pruebas, por ejemplo rg-demo.
• Un editor de texto (VS Code con la extensión Bicep ayuda, pero no es obligatorio).

Paso 1: Crear un archivo Bicep sencillo

Crea un archivo llamado main.bicep que declare un Storage Account. Es el recurso que what-if va a analizar:

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'
}

El nombre de un Storage Account debe ser único a nivel global: solo letras minúsculas y números, entre 3 y 24 caracteres.

Paso 2: Asegurarte de que el resource group existe

what-if necesita un ámbito con el que comparar. Si aún no tienes uno, crea el resource group:

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

Paso 3: Ejecutar what-if

Ahora pide a la Azure CLI que calcule la diferencia entre tu archivo y lo que ya existe en el resource group. Como el Storage Account todavía no existe, el resultado debería ser una creación:

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

what-if envía tu template a Azure, que lo compara con el estado actual y devuelve solo las diferencias. En esta fase no se modifica ningún recurso. Sustituye stbconceptsdemo01 por un nombre libre que respete las reglas del Paso 1.

Paso 4: Leer el resultado

what-if muestra cada recurso con un símbolo y un color delante. Estos son los que verás con más frecuencia:

• + Create: el recurso se va a crear.
• ~ Modify: el recurso ya existe y va a cambiar; la salida lo muestra propiedad a propiedad.
• - Delete: el recurso se va a eliminar.
• = NoChange: se queda exactamente igual.
• ! Ignore: está fuera del ámbito y no se toca.

En esta primera ejecución deberías ver una línea que empieza por + con la ruta Microsoft.Storage/storageAccounts/stbconceptsdemo01, señal de que la creación está lista para avanzar.

Paso 5: Provocar un Modify

Para ver a what-if detectar un cambio, haz primero el despliegue real y solo después edita el archivo. Aplica el Bicep:

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

Abre main.bicep y cambia el SKU de Standard_LRS a Standard_GRS. Ejecuta de nuevo el comando del Paso 3: en lugar de Create, ahora deberías ver ~ Modify, con la línea sku.name pasando de un valor al otro.

Comprobar el resultado

Sabes que funciona cuando el resumen final de what-if refleja tu intención. La CLI termina con un recuento del tipo Resource changes: 1 to create en la primera ejecución y 1 to modify después de tocar el SKU. Si ves 0 to create, 0 to modify cuando esperabas cambios, comprueba que apuntas al resource group correcto y que guardaste el archivo.

Conclusión

Con what-if obtienes una vista previa fiable de cada despliegue de Bicep, lo que reduce mucho el riesgo de crear, cambiar o eliminar algo sin querer. El siguiente paso natural es incluir este comando en tus pipelines de CI/CD, para que cada Pull Request muestre el impacto en la infraestructura antes de aprobar. Un consejo para el día a día: usa az deployment group create --confirm-with-what-if para ver el diff y confirmar el despliegue en el mismo comando. ¿En qué punto de tu flujo de trabajo te daría más tranquilidad esta vista previa?