Azure Developer CLI: novedades mayo-junio 2026

Microsoft cerró mayo y junio de 2026 con un combo de actualizaciones para Azure Developer CLI que van bastante más allá de un parche cosmético. Hooks en Python, JavaScript, TypeScript y .NET, el comando azd update en preview público (chau flag alpha), un framework de extensiones renovado y verificaciones automáticas de cuota de modelos AI antes de aprovisionar. Todo junto en dos meses. Si usás azd a diario, hay cambios que te van a cambiar el flujo de trabajo.

Azure Developer CLI (azd) es la herramienta de línea de comandos de Microsoft que te permite crear, aprovisionar y desplegar aplicaciones completas en Azure usando plantillas estandarizadas. Con un solo comando gestionás infraestructura como código, configuración de servicios y pipelines de CI/CD, sin tener que saltar entre el portal, la CLI de Azure y GitHub Actions como un malabarista.

¿Qué son los hooks multi-lenguaje en azd?

Hasta abril de 2026, si querías ejecutar lógica custom antes o después de un deploy con azd, tus opciones eran Bash o PowerShell. Punto. Para equipos que laburan con Python o Node, eso significaba empaquetar toda la lógica en scripts del sistema operativo, con el infierno de compatibilidad que eso trae entre Windows y Linux. Una molestia.

Con el release de abril 2026, azd incorporó hooks en Python, JavaScript, TypeScript y .NET. La CLI detecta automáticamente el runtime por la extensión del archivo y, si encontrás un requirements.txt, un package.json o un .csproj en el directorio del hook, restaura las dependencias antes de ejecutar. Sin configuración extra. (Bueno, casi: podés afinar el comportamiento con un bloque config: en el azure.yaml si necesitás algo más específico.)

El azure.yaml ahora acepta una sección hooks donde definís qué script corre en cada evento (preprovision, postdeploy, etc.) y el ejecutor que querés usar. Algo así como decidir “este hook de validación lo escribo en Python, pero el de cleanup lo dejo en Bash”. Cada uno en su idioma.

¿Cómo se actualiza azd con el nuevo comando azd update?

Hasta que se lanzó la preview pública de azd update en abril de 2026, mantener azd al día era una de esas tareas que demandaban ir a GitHub, buscar el release, bajar el instalador, cruzar los dedos. El flag alpha existía, pero con todas las limitaciones de algo experimental. En abril, Microsoft movió azd update a preview público y ahora funciona en Windows, macOS y Linux con un solo comando.

El mecanismo es simple: ejecutás azd update, la CLI verifica la versión más reciente, descarga el binario y reemplaza la instalación actual. En Windows incluye verificación de firma MSI del paquete, así que no hay sorpresas con binarios adulterados. La pregunta es si alguna vez no tuviste que googlear “how to update azd” a las apuradas porque un template nuevo pedía una versión que no tenías. ¿La respuesta? Sí, claro, a todos nos pasó. Relacionado: en nuestro análisis comparativo de Microsoft y GitHub.

¿Qué mejoras trajo el framework de extensiones de azd?

El modelo de extensiones de azd venía flojo. Lo que Microsoft anunció en abril 2026 es un framework renovado (todavía en beta, ojo) que ataca tres frentes donde la flexibilidad hacía agua: provisioning providers custom, resolución de secretos y gestión de actualizaciones.

Primero, los proveedores de infraestructura custom: ahora podés registrar un proveedor alternativo a Bicep o Terraform y azd lo invoca durante el aprovisionamiento sin que tengas que hacer maromas con scripts wrapper. Pensá en un equipo que usa Pulumi internamente y quiere mantener ese estándar sin abandonar el ecosistema azd. Segundo, la resolución de Key Vault en variables de entorno: si una variable referencia un secreto de Key Vault, azd lo resuelve automáticamente antes de inyectarlo en el entorno de deployment. Tercero, la migración automática de extensiones entre registros: cuando una extensión se promueve de un registro de testing a uno productivo, azd maneja la transición sin que vos tengas que reconfigurar nada.

El punto débil es que sigue en beta. Para equipos que requieran estabilidad absoluta, habría que esperar al release general. Pero el andamiaje ya está montado.

¿Cómo ayuda el preflight check de cuota de modelos AI?

Ponele que estás armando un deployment que incluye un modelo de OpenAI en Cognitive Services. Corrés azd provision, se despliega todo, y sobre el final explota porque la suscripción no tiene cuota para ese modelo en esa región. Resultado: perdiste 15 minutos de provisionamiento y tenés que abrir un ticket de soporte para que te aumenten la cuota. Un clásico.

Hasta la fecha (2026-06-27), azd provision ejecuta un preflight check de cuota antes de tocar infraestructura. La CLI consulta la cuota disponible para los modelos de Cognitive Services que definiste en tu template, y si detecta que estás al límite o que un modelo no está reconocido en la región, te larga una advertencia (y dependiendo del caso, frena el deployment). Es de esas mejoras que parecen menores pero que te salvan de iteraciones frustrantes. Sobre eso hablamos en como documentamos en el caso de los repos hackeados.

¿Qué cambios de seguridad se incluyeron en azd?

Seguridad en herramientas de infraestructura como código es terreno pantanoso: un descuido y exponés credenciales, secretos o permitís que alguien se haga pasar por un binario legítimo. En este ciclo, Microsoft metió tres ajustes concretos.

El primero es la verificación de firma MSI en Windows que mencioné antes — el instalador de azd update viene firmado y la CLI chequea la firma antes de proceder. El segundo es la corrección de una fuga de variables de entorno entre extensiones y el proceso principal de azd: antes, una extensión maliciosa (o mal escrita) podía leer variables que no le correspondían; ahora el scope está aislado. El tercero es la validación de nombres reservados — MICROSOFT, WINDOWS, AZURE y derivados — en recursos creados vía azd. Si intentás nombrar un recurso con una palabra bloqueada, la CLI lo rechaza en vez de mandarlo a Azure y comerse un error críptico del API.

¿Qué breaking changes debo conocer en azd?

Acá hay que prestar atención, porque tres cambios de abril 2026 pueden romper flujos automatizados si no los tenés en cuenta.

App Service slot targeting: antes, azd manejaba el deploy a slots de forma implícita. Ahora tenés que definir explícitamente la variable AZD_DEPLOY_{SERVICE}_SLOT_NAME para cada servicio que apunte a un slot específico. Si tu pipeline asumía el comportamiento viejo, arranca a fallar en silencio (o peor, deploya en el slot equivocado). azd init -t: el flag -t (template) ahora crea un directorio nuevo por defecto. Antes sobrescribía el directorio actual; el cambio es por seguridad, pero si tenías scripts que asumían lo contrario, se rompen. Eliminación del patrón ambient-authority: InitializeAsync ya no acepta el patrón ambient-authority. Si tu código de extensión lo usaba, vas a tener que migrar a los nuevos hooks de inicialización.

Son cambios con sentido técnico, pero implementados todos juntos en un mismo ciclo. Si mantenés varios proyectos con azd, revisá los pipelines antes de actualizar la CLI. Más contexto en según la comparativa de pipelines CI/CD de 2026.

¿Cómo integrar azd con GitHub Copilot?

La integración con Copilot viene gestándose desde marzo 2026 y en el ciclo abril-mayo sumó funciones nuevas. La más práctica es la opción “Fix this error” en el flujo de troubleshooting: cuando un comando de azd falla, Copilot analiza el error, el contexto del proyecto y te propone una corrección directamente en la terminal. No es magia — a veces la sugerencia es genérica — pero en errores comunes de configuración de templates ahorra buenos minutos de debugging.

La otra pata es Copilot en azd init: al inicializar un proyecto nuevo, Copilot te asiste con la configuración, sugiriendo valores para variables de entorno, nombres de recursos y detectando patrones en el código fuente para recomendar el template más adecuado. Si ya usás Copilot en VS Code, la experiencia es parecida, pero metida dentro del flujo de inicialización de azd. No reemplaza conocer la herramienta, pero acelera el setup inicial, sobre todo para gente que recién arranca con Azure.

Funcionalidad	Estado	Disponible desde
Hooks multi-lenguaje (Python, JS, TS, .NET)	General Availability	Abril 2026
azd update	Preview público	Abril 2026
Custom provisioning providers	Beta	Abril 2026
Key Vault en variables de entorno	Beta	Abril 2026
Preflight check cuota modelos AI	General Availability	Abril 2026
Verificación firma MSI (Windows)	General Availability	Abril 2026
Fix this error con Copilot	Preview	Mayo 2026
Copilot en azd init	Preview	Marzo 2026

Qué significa para empresas y equipos en Latinoamérica

En equipos de la región, donde muchas veces se labura con suscripciones de Azure que tienen cuotas ajustadas (por presupuesto o por políticas de la organización), el preflight check de modelos AI es un golazo. Evitás el ciclo de “provisiono, falla, pido cuota, espero, reprovisiono” que te come horas de un sprint.

Los hooks multi-lenguaje bajan la barrera para equipos que no tienen expertise en Bash y prefieren mantenerse en Python o JavaScript — que en el mercado local son los stacks más comunes. Si ya tenés tu lógica de validación y deploy en Node o Python, ahora la conectás directo al flujo de azd sin tener que traducirla a shell script. Y si estás evaluando dónde alojar tus aplicaciones o necesitás dominios para tus entornos de desarrollo, un proveedor como donweb.com te cubre el lado de hosting y dominios mientras Azure maneja la infraestructura pesada.

Errores comunes

Actualizar azd sin revisar los breaking changes: si tenés pipelines que usan azd init -t en un directorio existente, después de actualizar el comando va a crear una subcarpeta nueva en vez de sobrescribir. Revisá tus scripts de CI antes de correr azd update.

Asumir que los hooks en Python no necesitan dependencias declaradas: azd busca requirements.txt; si tu script usa librerías externas y ese archivo no existe, el hook falla sin mucho misterio. Creá el archivo aunque tenga una sola dependencia.

Ignorar la variable de slot en App Service: si deployabas a un slot de staging y ahora el deploy va al slot de producción sin que te des cuenta, el problema es que no definiste AZD_DEPLOY_{SERVICE}_SLOT_NAME. Verificá dos veces. Complementá con tal como detallamos en la comparativa entre Jenkins y GitHub Actions.

Usar nombres reservados sin saberlo: nombrar un recurso “MICROSOFT-procesamiento” o “WINDOWS-batch” ahora es rechazado por azd antes de llegar a Azure. Si migrás templates viejos, chequeá que los nombres de recursos no incluyan palabras bloqueadas.

Preguntas Frecuentes

¿Cómo instalo o actualizo Azure Developer CLI en 2026?

Ejecutá winget install Microsoft.Azd en Windows, brew install azd en macOS o usá el script de instalación oficial en Linux. Si ya lo tenés instalado, azd update lo actualiza a la última versión desde cualquier plataforma sin pasos manuales. El comando está en preview público desde abril 2026.

¿En qué lenguajes puedo escribir hooks en azd?

Desde abril 2026, azd soporta hooks en Python, JavaScript, TypeScript, .NET, Bash y PowerShell. La CLI detecta el runtime automáticamente por la extensión del archivo y restaura dependencias desde requirements.txt, package.json o .csproj según corresponda.

¿El comando azd update funciona en todas las plataformas?

Sí. azd update funciona en Windows, macOS y Linux desde abril 2026, cuando Microsoft lo movió a preview público. En Windows incluye verificación de firma MSI para garantizar la integridad del binario descargado.

¿Qué pasa si excedo la cuota de modelos AI al aprovisionar?

Antes del despliegue, azd provision ejecuta un preflight check que consulta la cuota disponible en Cognitive Services. Si detecta que un modelo está al límite o no está reconocido en la región, emite una advertencia o frena el aprovisionamiento antes de tocar infraestructura.

¿Los breaking changes de 2026 afectan proyectos existentes?

Posiblemente sí. Tres cambios de abril 2026 pueden impactar flujos existentes: App Service ahora requiere la variable AZD_DEPLOY_{SERVICE}_SLOT_NAME para deployar a slots, azd init -t crea un directorio nuevo por defecto en vez de sobrescribir, y el patrón ambient-authority en InitializeAsync fue eliminado.

Conclusión

Azure Developer CLI maduró fuerte en este ciclo de mayo-junio 2026. Los hooks multi-lenguaje y el preflight check de cuota AI resuelven fricciones reales del día a día, de esas que te hacen putear frente al monitor. El framework de extensiones, aunque en beta, deja entrever hacia dónde va la herramienta: menos monolito, más ecosistema abierto.

Los breaking changes son manejables, pero requieren una revisión consciente de pipelines y scripts antes de actualizar. Si mantenés infraestructura en Azure, dedicarle una hora a chequear esos tres puntos te va a ahorrar dolores de cabeza en el próximo deploy. La integración con Copilot sigue en evolución y, sin ser revolucionaria, ya empieza a ser útil en troubleshooting.

El resumen es simple: azd en 2026 es más flexible, más segura y más consciente de las limitaciones reales de una suscripción de Azure. Si no la actualizaste todavía, este es el momento.

Fuentes

• Azure Developer CLI (azd) – May and June 2026 — anuncio oficial en el blog de Azure SDK
• Azure Developer CLI (azd) – April 2026 — release notes oficial con hooks multi-lenguaje, azd update y cambios de seguridad
• Azure Developer CLI: actualización abril 2026 — cobertura con detalle de hooks, extensiones y preflight check
• Azure Developer CLI (azd) – March 2026 — release con integración inicial de Copilot en azd init