Azure Developer CLI abril 2026: todas las novedades
Microsoft lanzó en abril de 2026 la actualización mensual de Azure Developer CLI (azd), sumando soporte multi-lenguaje para hooks (Python, JavaScript, TypeScript y .NET), un comando unificado azd update en preview público, mejoras de integración con GitHub Copilot y un framework de extensiones en beta. La actualización también incluye fixes de seguridad y breaking changes que afectan flujos existentes.
En 30 segundos
- Los hooks de azd ahora se pueden escribir en Python, JavaScript, TypeScript y .NET, no solo Bash/PowerShell.
azd updateestá en preview público: un solo comando para actualizar la herramienta en cualquier plataforma.- Nueva integración con GitHub Copilot: preflight checking de cuotas de modelos IA y opción “Fix this error” con agentes.
- Breaking change crítico:
azd init -tahora crea directorios con nombre propio en vez de usar el directorio actual. - El framework de extensiones está en beta, permitiendo proveedores de provisioning alternativos a Bicep.
Microsoft es una empresa estadounidense de tecnología fundada en 1975 que desarrolla software, sistemas operativos y servicios en la nube. Es responsable de productos como Windows, Microsoft 365 y Microsoft Azure.
¿Qué es Azure Developer CLI (azd)?
Azure Developer CLI es una herramienta de línea de comandos de Microsoft que permite a los desarrolladores pasar de código local a una aplicación desplegada en Azure con un conjunto reducido de comandos de alto nivel como azd up, azd deploy y azd down. No reemplaza a Azure CLI (az), sino que opera en una capa de abstracción superior: en vez de gestionar recursos individuales, manejás templates de aplicaciones completas con infraestructura como código incluida.
Si alguna vez tuviste que coordinar a mano Bicep, GitHub Actions y configuración de entornos para deployar algo en Azure, sabés exactamente qué problema resuelve azd.
Soporte multi-lenguaje para hooks: Python, JavaScript, TypeScript y .NET
Este es el cambio más significativo de la actualización de abril de 2026, según el blog oficial de Azure SDK. Los hooks de azd son scripts que se ejecutan antes o después de comandos como azd up, azd provision o azd deploy. Hasta ahora, estaban limitados a Bash y PowerShell.
Ponele que necesitás validar configuración, generar archivos dinámicos o hacer llamadas a una API antes de provisionar infraestructura. Con la restricción anterior, terminabas escribiendo lógica compleja en Bash (lo que ya de por sí es una experiencia de vida), o creando scripts auxiliares que invocabas desde Bash.
Con los nuevos hooks multi-lenguaje, podés definir directamente en azure.yaml cuál script ejecutar y en qué runtime:
- Python: para equipos de data/ML que ya tienen scripts de setup en ese lenguaje
- JavaScript/TypeScript: para proyectos fullstack donde el mismo equipo frontend maneja la infra
- .NET: para organizaciones con estándares corporativos en ese ecosistema
La ventaja práctica no es menor: reutilizás código existente del proyecto sin traducirlo. El hook de validación que ya tenías en Python no necesita reescribirse en PowerShell para funcionar en el pipeline. Complementá con estrategias SEO para alcance global.
Integración mejorada con GitHub Copilot e IA
Para los que trabajen con modelos de IA en Azure, esta actualización suma tres cosas concretas.
La primera es preflight checking de cuotas de modelos: antes de intentar provisionar un modelo de IA, azd verifica que la cuota disponible en tu suscripción sea suficiente para el deployment que estás pidiendo. Suena obvio, pero hasta ahora el flujo era: iniciar el deployment, esperar varios minutos, recibir un error de cuota, investigar manualmente. (Spoiler: ese ciclo le había costado más de una hora a más de un equipo.)
La segunda es la opción “Fix this error” integrada con agentes de Copilot. Cuando un deployment falla, azd puede invocar un agente que analiza el error y propone una corrección contextualizada. No es magia, y el agente no siempre da con la causa raíz, pero para errores comunes de configuración acelera bastante el diagnóstico.
Tercera: localización inteligente de capacidad de modelos. Azd puede sugerir regiones de Azure donde hay disponibilidad del modelo que querés deployar, en vez de dejarte adivinar en cuál región está el cupo libre.
Comando azd update: la actualización que faltaba
Antes de esta versión, actualizar azd dependía del package manager de cada sistema operativo: winget upgrade en Windows, brew upgrade en macOS, o el script de instalación en Linux. No era dramático, pero sí molesto si trabajabas en equipos mixtos o tenías scripts de CI que necesitaban la última versión.
El nuevo azd update está en preview público y unifica todo eso en un solo comando que funciona independientemente de cómo instalaste la herramienta originalmente. Para CI/CD, esto simplifica los pipelines de onboarding de nuevos entornos. Para uso local, es comodidad directa. En soluciones de seguridad en Azure profundizamos sobre esto.
Ojo: está en preview, así que el comportamiento puede cambiar antes de llegar a GA.
Framework de extensiones (beta) y proveedores personalizados
Esta es la apuesta más ambiciosa de la actualización, y también la que viene con más asteriscos.
El framework de extensiones en beta permite crear plugins para azd que extiendan su comportamiento de formas que antes requerían forks o workarounds. Dos casos de uso que Microsoft destacó:
- Proveedores de provisioning alternativos: en vez de Bicep, podés usar Terraform u otras herramientas de IaC con el mismo flujo de azd. Para equipos que ya tienen inversión en Terraform, esto evita mantener dos sistemas paralelos.
- Resolución de secretos desde Key Vault: las extensiones pueden conectarse a Azure Key Vault para resolver secretos durante el ciclo de vida de azd, sin necesidad de exponer valores en el entorno local.
¿Qué tan maduro está? Beta quiere decir que la API puede cambiar entre versiones. Si empezás a construir extensiones ahora, contá con que vas a tener que actualizarlas cuando llegue la versión estable. Para explorar y evaluar, adelante. Para ponerlo en producción de un cliente, esperá un ciclo más.
Mejoras de seguridad, rendimiento e IaC
Tres áreas con cambios más técnicos pero relevantes para uso en producción.
Seguridad: la actualización incorpora verificación de firma del instalador MSI en Windows, lo que permite confirmar que el binario que instalaste viene efectivamente de Microsoft y no fue modificado. También se corrigió un bug de leak de variables de entorno que podía exponer valores sensibles en logs bajo ciertas condiciones. Este último fix justifica solo la actualización si usás azd en entornos con secretos.
Rendimiento: connection pooling para llamadas a la API de Azure (reduce latencia en operaciones con múltiples recursos), polling adaptivo de ARM (en vez de intervals fijos, ajusta la frecuencia según el estado del deployment) y caching de Azure Container Registry. En deployments grandes, estos cambios pueden reducir tiempos de varios minutos a menos de la mitad, aunque va a depender mucho de la arquitectura específica. Te puede servir nuestra cobertura de confiabilidad de plataformas DevOps.
IaC: soporte para archivos .azdignore y .azdxignore, similar en concepto a .gitignore, para excluir archivos o directorios de las operaciones de azd. Útil para repos donde tenés código de múltiples proyectos y no querés que azd procese todo.
Breaking changes: leer antes de actualizar
Acá viene lo importante para los que ya usan azd en producción o en pipelines automatizados.
| Cambio | Comportamiento anterior | Comportamiento nuevo | Impacto |
|---|---|---|---|
azd init -t <template> | Descargaba el template en el directorio actual | Crea un directorio con el nombre del template | Alto: scripts de CI que asumen la ruta anterior se rompen |
| App Service slots targeting | Configuración implícita según el nombre del servicio | Requiere variable explícita AZD_DEPLOY_{SERVICE}_SLOT_NAME | Medio: deployments a slots dejan de funcionar sin la variable |
El cambio de azd init -t es el más frecuente. Si tenés un script de onboarding que hace azd init -t nombre-template y después accede a archivos en el directorio actual, va a necesitar un cd nombre-template después del init. No es complejo de arreglar, pero si no lo sabés, el error no es obvio.
Para App Service slots, revisá todos los servicios que usaban slots implícitos y agregá la variable de entorno correspondiente en tu configuración de azd antes de actualizar.
Comparativa: Azure Developer CLI vs Azure CLI
| Aspecto | Azure CLI (az) | Azure Developer CLI (azd) |
|---|---|---|
| Nivel de abstracción | Recursos individuales | Aplicaciones completas con IaC |
| Curva de entrada | Alta (muchos subcomandos) | Baja para templates estándar |
| IaC incluida | No | Sí (Bicep por defecto, Terraform vía extensión) |
| Casos de uso principales | Administración de recursos, scripting específico | Desarrollo, CI/CD, onboarding de proyectos |
| Hooks multi-lenguaje | No aplica | Sí (Python, JS, TS, .NET desde abril 2026) |
| Integración con Copilot | Básica | Avanzada (fix errors, preflight checks) |
No son herramientas competidoras. En proyectos reales las usás juntas: azd para el ciclo de vida completo de la aplicación, az para operaciones puntuales sobre recursos específicos.
Errores comunes al trabajar con azd
Confundir azd con az
Es el error más clásico de los que llegan a azd desde Azure CLI. Intentan hacer con azd lo que harían con az (crear un storage account individual, listar VMs, gestionar permisos) y se frustran porque la herramienta opera a otro nivel. Azd trabaja con el concepto de “aplicación”, no de recurso suelto. Si necesitás gestionar un recurso específico fuera del contexto de una aplicación azd, usá az. Cubrimos ese tema en detalle en despliegue automatizado con contenedores.
No revisar breaking changes antes de actualizar en CI
Azd publica notas de versión mensuales, pero es frecuente que los equipos actualicen la herramienta en pipelines sin revisar qué cambió. Con la actualización de abril 2026, el cambio en azd init -t y el nuevo requerimiento de AZD_DEPLOY_{SERVICE}_SLOT_NAME pueden romper deployments silenciosamente (el pipeline “pasa” pero deploya al lugar equivocado o usa configuración legacy).
Tratar los hooks como simples scripts de utilidad
Con el nuevo soporte multi-lenguaje, es tentador meter lógica compleja de negocio en los hooks. El problema: los hooks no tienen acceso al contexto completo del deployment, corren en un proceso separado, y si fallan con ciertos exit codes pueden dejar el estado de azd inconsistente. Usá hooks para tareas de validación y preparación liviana, no para orquestar workflows enteros.
Asumir disponibilidad de modelos IA sin preflight check
Cualquiera que haya intentado deployar un modelo de IA en Azure se topó con el error de cuota disponible en la región equivocada. Con el nuevo preflight checking, azd puede detectar esto antes de iniciar el deployment. Pero el check tiene que estar habilitado en la configuración del template. Si usás templates viejos sin actualizar, seguís con el comportamiento anterior.
Preguntas Frecuentes
¿Cuáles son las novedades de Azure Developer CLI en 2026?
La actualización de abril de 2026 sumó soporte para hooks en Python, JavaScript, TypeScript y .NET; el comando azd update en preview público para actualizaciones unificadas; integración con GitHub Copilot para preflight de cuotas y fix asistido de errores; y un framework de extensiones en beta. También hay fixes de seguridad (verificación de firma MSI, corrección de leak de variables de entorno) y breaking changes en azd init -t y el targeting de App Service slots.
¿Azure Developer CLI soporta Python?
Desde abril de 2026, sí. Los hooks de azd (scripts que corren antes o después de comandos como azd up o azd deploy) ahora pueden escribirse en Python, además de JavaScript, TypeScript, .NET, Bash y PowerShell. Esto permite reutilizar scripts existentes del proyecto sin reescribirlos en otro lenguaje.
¿Cómo actualizar Azure Developer CLI en Windows?
A partir de la versión de abril de 2026, podés usar el nuevo comando azd update (en preview público) que funciona en cualquier plataforma. Alternativamente, el método anterior sigue funcionando: winget upgrade Microsoft.Azd en Windows o el script oficial de instalación. Para entornos corporativos donde winget no está disponible, Microsoft publica el instalador MSI en el repositorio oficial en GitHub.
¿Qué diferencia hay entre Azure CLI y Azure Developer CLI?
Azure CLI (az) opera a nivel de recursos individuales: crear una VM, configurar un storage account, gestionar permisos. Azure Developer CLI (azd) opera a nivel de aplicaciones completas: toma un template con código e IaC y gestiona todo el ciclo de vida del deployment con comandos de alto nivel como azd up y azd down. En la práctica, se usan juntas, no en reemplazo una de la otra.
¿Cómo crear extensiones personalizadas con azd?
El framework de extensiones de azd está en beta desde abril de 2026. Permite crear providers de provisioning alternativos a Bicep (como Terraform) y extender la resolución de secretos desde Azure Key Vault. La documentación oficial está en Microsoft Learn. Por estar en beta, la API puede cambiar entre versiones, así que no conviene usarlo en producción crítica todavía.
Conclusión
La Azure Developer CLI actualización de abril de 2026 tiene una dirección clara: hacer que azd sirva para más equipos, no solo para los que viven en Bash y PowerShell. El soporte multi-lenguaje para hooks es el cambio más tangible del ciclo, y la integración creciente con Copilot apunta a que Microsoft quiere que azd sea la interfaz natural entre el código del desarrollador y Azure, con IA de por medio.
Dicho esto, si ya usás azd en producción, la prioridad ahora mismo es revisar los breaking changes antes de actualizar cualquier pipeline. El cambio en azd init -t y el nuevo requerimiento de targeting explícito para slots son los que más frecuentemente van a causar problemas en entornos existentes. Con eso despejado, la actualización vale la pena.
Para los que están evaluando si vale incorporar azd a su flujo de trabajo con Azure: este ciclo reduce dos de las fricciones principales (lenguaje de hooks y actualización multiplataforma). Si tu equipo ya tiene scripts de setup en Python o TypeScript, ahora integrarse a azd tiene un costo de adopción bastante menor.
