Cloud | The .NET Blog

Actualizaciones de Azure Developer CLI (azd) para abril de 2026

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Azure Developer CLI (azd) lanzó cinco versiones en abril de 2026 (1.23.14 a 1.24.2), con el gran protagonismo de los hooks que ahora se ejecutan en Python, JavaScript, TypeScript y .NET, no solo en Bash y PowerShell.

Hooks en varios lenguajes en azure.yaml

Los hooks ahora pueden apuntar a archivos .py, .js, .ts o .cs además de scripts de shell. Cada lenguaje obtiene resolución automática de dependencias:

Python — detecta requirements.txt o pyproject.toml, crea un virtualenv e instala las dependencias antes de ejecutarse. Configura el nombre del entorno con virtualEnvName.
JavaScript / TypeScript — detecta package.json y ejecuta npm install automáticamente. TypeScript se ejecuta mediante npx tsx sin necesidad de un paso de compilación. Elige tu gestor de paquetes con el bloque de configuración packageManager.
.NET — ejecuta archivos .cs con dotnet run. Se admiten scripts de un solo archivo en .NET 10+. Configura el framework de destino mediante el bloque configuration/framework.

Esto significa que los equipos que ya trabajan en uno de estos lenguajes ya no necesitan mantener un hook de Bash o PowerShell separado solo para conectar eventos del ciclo de vida del aprovisionamiento.

azd update llega a vista previa pública

azd update está ahora en vista previa pública en todas las plataformas. Un único comando gestiona la actualización independientemente de cómo se instaló azd originalmente: sin tener que rastrear rutas de Homebrew, WinGet o MSI por separado.

Modo no interactivo mediante AZD_NON_INTERACTIVE

Establecer AZD_NON_INTERACTIVE=true (o usar --non-interactive / --no-prompt) ahora produce fallos consistentes y deterministas en pipelines de CI/CD cuando una entrada requerida no puede resolverse automáticamente. Anteriormente, el comportamiento era inconsistente entre comandos.

Comprobación previa de cuota de modelos de IA

azd provision valida la cuota de Azure Cognitive Services antes de intentar aprovisionar recursos de modelos de IA. Las implementaciones que fallarían por límites de cuota ahora muestran el error al inicio del proceso en lugar de a mitad del aprovisionamiento.

“Corregir este error” en la solución de problemas de Copilot

La integración de solución de problemas de Copilot en azd gana la capacidad de aplicar directamente una corrección sugerida, no solo describirla. Cuando el agente identifica un problema corregible, puede realizar el cambio in situ.

Proveedores de aprovisionamiento personalizados y resolución de secretos de Key Vault

Los autores de extensiones ahora pueden registrar backends de infraestructura alternativos con WithProvisioningProvider(). Por separado, azd resuelve automáticamente las referencias @Microsoft.KeyVault(...) antes de pasar la configuración a las extensiones, eliminando la necesidad de resolución manual de secretos en proveedores personalizados.

Exclusiones de plantillas y modo de vigilancia

Dos nuevos archivos de ignorados ofrecen un control más fino sobre el manejo de archivos:

.azdignore — excluye archivos solo para colaboradores (documentación, configuraciones de CI) de las copias de plantillas para que los usuarios finales obtengan un proyecto limpio.
.azdxignore — excluye directorios de disparar reconstrucciones durante azd x watch, reduciendo el ruido durante el desarrollo iterativo.

Comprobación previa de nombres reservados y opción docker.network

azd ahora advierte cuando los nombres de recursos predichos contienen palabras reservadas de Azure (MICROSOFT, WINDOWS o el prefijo LOGIN) antes de comenzar el aprovisionamiento. Una nueva opción docker.network pasa --network a docker build, útil en entornos de proxy corporativo que requieren una red Docker específica.

Correcciones de seguridad

El paquete MSI de Windows ahora incluye verificación de firma de código. Una corrección separada cierra una fuga de variables de entorno que podía exponer valores entre los límites de comandos de extensión.

Un mes cargado — el soporte de hooks en múltiples lenguajes en particular elimina un punto de fricción real para equipos que no trabajan principalmente en Bash. Consulta las notas de versión completas para el registro de cambios completo de las cinco versiones.

Tus experimentos de IA en Azure están quemando dinero — Así es como solucionarlo

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Si estás construyendo aplicaciones con IA en Azure ahora mismo, probablemente hayas notado algo: tu factura de la nube se ve diferente a como solía ser. No solo más alta — más rara. Con picos. Difícil de predecir.

Microsoft acaba de publicar un excelente artículo sobre principios de optimización de costos en la nube que siguen importando, y honestamente, el momento no podría ser mejor. Porque las cargas de trabajo de IA han cambiado las reglas del juego en cuanto a costos.

Por qué las cargas de trabajo de IA pegan diferente

La cosa es esta. Las cargas de trabajo tradicionales de .NET son relativamente predecibles. Conoces tu nivel de App Service, conoces tus DTUs de SQL, puedes estimar el gasto mensual con bastante precisión. ¿Cargas de trabajo de IA? No tanto.

Estás probando múltiples modelos para ver cuál encaja. Estás levantando infraestructura con GPU para fine-tuning. Estás haciendo llamadas a la API de Azure OpenAI donde el consumo de tokens varía enormemente dependiendo de la longitud del prompt y el comportamiento del usuario. Cada experimento cuesta dinero real, y podrías ejecutar docenas antes de dar con el enfoque correcto.

Esa imprevisibilidad es lo que hace que la optimización de costos sea crítica — no como algo secundario, sino desde el día uno.

Gestión vs. optimización — conoce la diferencia

Una distinción del artículo que creo que los desarrolladores pasan por alto: hay una diferencia entre gestión de costos y optimización de costos.

La gestión es seguimiento y reportes. Configuras presupuestos en Azure Cost Management, recibes alertas, ves dashboards. Eso es lo básico.

La optimización es donde realmente tomas decisiones. ¿Realmente necesitas ese tier S3, o el S1 manejaría tu carga? ¿Esa instancia de compute siempre encendida está ociosa los fines de semana? ¿Podrías usar instancias spot para tus trabajos de entrenamiento?

Como desarrolladores .NET, tendemos a enfocarnos en el código y dejar las decisiones de infraestructura al “equipo de operaciones”. Pero si estás desplegando en Azure, esas decisiones también son tus decisiones.

Qué es lo que realmente funciona

Basándome en el artículo y en mi propia experiencia, esto es lo que marca la diferencia:

Sabe qué estás gastando y dónde. Etiqueta tus recursos. En serio. Si no puedes distinguir qué proyecto o experimento se está comiendo tu presupuesto, no puedes optimizar nada. Azure Cost Management con etiquetado adecuado es tu mejor aliado.

Establece límites antes de experimentar. Usa Azure Policy para restringir SKUs costosos en entornos de dev/test. Establece límites de gasto en tus despliegues de Azure OpenAI. No esperes a que llegue la factura para darte cuenta de que alguien dejó un clúster de GPU corriendo todo el fin de semana.

Ajusta el tamaño continuamente. ¿Esa VM que elegiste durante el prototipado? Probablemente no sea la correcta para producción. Azure Advisor te da recomendaciones — realmente míralas. Revisa mensualmente, no anualmente.

Piensa en el ciclo de vida. Los recursos de desarrollo deberían apagarse. Los entornos de prueba no necesitan correr 24/7. Usa políticas de apagado automático. Para cargas de trabajo de IA específicamente, considera opciones serverless donde pagas por ejecución en lugar de mantener el compute encendido.

Mide el valor, no solo el costo. Esta es fácil de olvidar. Un modelo que cuesta más pero entrega resultados significativamente mejores podría ser la decisión correcta. El objetivo no es gastar lo menos posible — es gastar inteligentemente.

La conclusión

La optimización de costos en la nube no es una limpieza de una sola vez. Es un hábito. Y con las cargas de trabajo de IA haciendo que el gasto sea menos predecible que nunca, construir ese hábito temprano te ahorra sorpresas dolorosas más adelante.

Si eres un desarrollador .NET construyendo sobre Azure, empieza a tratar tu factura de la nube como tratas tu código — revísala regularmente, refactoriza cuando se ponga desordenada, y nunca despliegues sin entender lo que te va a costar.