Azd | The .NET Blog

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Este artículo fue traducido automáticamente. Para ver la versión original en inglés, haz clic aquí.

¿Conoces ese momento en que quieres desplegar una app existente en Azure y te quedas mirando un azure.yaml en blanco, intentando recordar si tu API Express debería usar Container Apps o App Service? Ese momento acaba de volverse mucho más corto.

El Azure Developer CLI (azd) ahora se integra con GitHub Copilot de dos formas muy concretas: scaffolding asistido por IA durante azd init, y resolución inteligente de errores cuando los despliegues fallan. Ambas funciones se quedan completamente en tu terminal, que es exactamente donde quiero que estén.

Configuración con Copilot durante azd init

Cuando ejecutas azd init, ahora aparece la opción “Set up with GitHub Copilot (Preview)”. Selecciónala y Copilot analiza tu codebase para generar el azure.yaml, las plantillas de infraestructura y los módulos Bicep — basándose en tu código real, no en suposiciones.

azd init
# Selecciona: "Set up with GitHub Copilot (Preview)"

Para que funcione necesitas:

azd 1.23.11 o superior — comprueba con azd version o actualiza con azd update
Una suscripción activa de GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd pedirá login si es necesario

Lo que me parece genuinamente útil es que funciona en los dos sentidos. ¿Construyendo desde cero? Copilot te ayuda a configurar los servicios Azure correctos desde el principio. ¿Tienes una app existente que llevas tiempo sin desplegar? Apunta Copilot hacia ella y genera la configuración sin que tengas que reestructurar nada.

Lo que hace realmente

Imagina que tienes una API Express en Node.js con dependencia de PostgreSQL. En lugar de decidir manualmente entre Container Apps o App Service, y luego escribir Bicep desde cero, Copilot detecta tu stack y genera:

Un azure.yaml con los ajustes correctos de language, host y build
Un módulo Bicep para Azure Container Apps
Un módulo Bicep para Azure Database for PostgreSQL

Y hace comprobaciones previas antes de tocar nada — verifica que tu directorio git esté limpio, pide consentimiento para las herramientas del servidor MCP. Nada ocurre sin que sepas exactamente qué va a cambiar.

Resolución de errores potenciada por Copilot

Los errores de despliegue son inevitables. Parámetros faltantes, problemas de permisos, disponibilidad de SKUs — y el mensaje de error raramente te dice lo único que realmente necesitas saber: cómo solucionarlo.

Sin Copilot, el ciclo es: copiar el error → buscar en docs → leer tres respuestas irrelevantes de Stack Overflow → ejecutar algunos comandos az CLI → volver a intentarlo y rezar. Con Copilot integrado en azd, ese ciclo se colapsa. Cuando cualquier comando azd falla, ofrece inmediatamente cuatro opciones:

Explain — descripción en lenguaje natural de qué salió mal
Guidance — instrucciones paso a paso para solucionarlo
Diagnose and Guide — análisis completo + Copilot aplica la solución (con tu aprobación) + reintento opcional
Skip — gestionarlo tú mismo

Lo clave: Copilot ya tiene contexto sobre tu proyecto, el comando que falló y la salida del error. Sus sugerencias son específicas para tu situación, no documentación genérica.

Ejemplos reales donde brilla

Proveedor de recursos no registrado:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Esto falla a cualquiera que despliega en una suscripción nueva. Copilot puede registrar el proveedor y relanzar el despliegue automáticamente.

SKU no disponible:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot explica qué tamaño de VM o región está bloqueado y sugiere alternativas disponibles en tu suscripción.

Colisión de nombre de cuenta de almacenamiento:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

La unicidad global le pasa a todo el mundo al menos una vez. Copilot sugiere añadir el nombre del entorno o un sufijo aleatorio a tus parámetros Bicep.

Configurar un comportamiento predeterminado

Si siempre quieres la misma opción, salta el prompt interactivo:

azd config set copilot.errorHandling.category troubleshoot

Opciones: explain, guidance, troubleshoot, fix, skip. También puedes habilitar auto-fix y reintento:

azd config set copilot.errorHandling.fix allow

Vuelve al modo interactivo en cualquier momento:

azd config unset copilot.errorHandling.category

Por qué importa esto para los desarrolladores .NET

Si estás construyendo en Azure — ya sea una app .NET Aspire, una API en contenedor, o cualquier otra cosa — azd es la herramienta que debes conocer. Esta integración con Copilot elimina la última barrera de fricción que antes hacía que necesitaras una chuleta para empezar.

La pieza de scaffolding es genial para proyectos brownfield. Tienes una app ASP.NET Core funcionando localmente perfectamente, pero llevarla a Azure siempre ha requerido algo de conocimiento de infraestructura. Ahora Copilot tiende ese puente. Y la función de resolución de errores es algo que desearía haber tenido la última vez que pasé 45 minutos depurando un error SkuNotAvailable en tres regiones diferentes.

Conclusión

Esta es exactamente el tipo de integración de Copilot que aporta valor real — no IA por el gusto de la IA, sino IA que entiende tu contexto y te ahorra tiempo real. Pruébalo ejecutando azd update para obtener la última versión, y usa azd init en tu próximo proyecto. El equipo está trabajando en funciones más profundas incluyendo personalización de infraestructura asistida por Copilot, así que ahora es un buen momento para apuntarte a la investigación de usuarios.

Lee el anuncio original aquí.

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

¿Conoces ese mensaje de “Hay una nueva versión de azd disponible” que aparece cada pocas semanas? ¿Ese que ignoras porque no recuerdas si instalaste azd con winget, Homebrew o ese script de curl que ejecutaste hace seis meses? Bueno, eso por fin tiene solución.

Microsoft acaba de lanzar azd update — un único comando que actualiza Azure Developer CLI a la última versión sin importar cómo lo instalaste originalmente. Windows, macOS, Linux — da igual. Un solo comando.

Cómo funciona

azd update

Eso es todo. Si quieres acceso anticipado a nuevas funcionalidades, puedes cambiar a la build diaria de insiders:

azd update --channel daily
azd update --channel stable

El comando detecta tu método de instalación actual y usa el mecanismo de actualización apropiado internamente. Se acabó el “espera, ¿usé winget o choco en esta máquina?”

El pequeño detalle

azd update viene a partir de la versión 1.23.x. Si estás en una versión anterior, necesitarás hacer una última actualización manual usando tu método de instalación original. Después de eso, azd update se encarga de todo en adelante.

Comprueba tu versión actual con azd version. Si necesitas una instalación desde cero, la documentación de instalación te cubre.

Por qué importa

Es una pequeña mejora de calidad de vida, pero para los que usamos azd a diario para desplegar agentes de IA y apps de Aspire en Azure, estar actualizado significa menos momentos de “ese bug ya estaba corregido en la última versión”. Una cosa menos en la que pensar.

Lee el anuncio completo y el análisis más detallado de Jon Gallant para más contexto.

azd ahora te permite ejecutar y depurar agentes IA localmente — Esto es lo que cambió en marzo 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Siete versiones en un mes. Eso es lo que el equipo del Azure Developer CLI (azd) publicó en marzo 2026, y la función estrella es la que estaba esperando: un bucle local de ejecución y depuración para agentes IA.

PC Chan publicó el resumen completo, y aunque hay mucho contenido, déjame filtrarlo a lo que realmente importa para desarrolladores .NET que construyen apps con IA.

Ejecutar y depurar agentes IA sin desplegar

Esta es la grande. La nueva extensión azure.ai.agents añade un conjunto de comandos que te dan una experiencia de bucle interno adecuada para agentes IA:

azd ai agent run — inicia tu agente localmente
azd ai agent invoke — le envía mensajes (local o desplegado)
azd ai agent show — muestra el estado del contenedor y su salud
azd ai agent monitor — transmite logs del contenedor en tiempo real

Antes, probar un agente IA significaba desplegarlo en Microsoft Foundry cada vez que hacías un cambio. Ahora puedes iterar localmente, probar el comportamiento de tu agente, y solo desplegarlo cuando estés listo. Si has estado construyendo agentes con el Microsoft Agent Framework o Semantic Kernel, esto cambia tu flujo de trabajo diario.

El comando invoke funciona tanto contra agentes locales como desplegados, lo que significa que puedes usar el mismo flujo de pruebas sin importar dónde esté corriendo el agente. Ese es el tipo de detalle que te ahorra mantener dos conjuntos de scripts de prueba.

GitHub Copilot configura tu proyecto azd

azd init ahora ofrece una opción “Set up with GitHub Copilot (Preview)”. En lugar de responder prompts manualmente sobre la estructura de tu proyecto, un agente Copilot genera la configuración por ti. Verifica que el directorio de trabajo esté limpio antes de modificar archivos y pide consentimiento de herramientas MCP por adelantado.

Cuando un comando falla, azd ahora ofrece troubleshooting asistido por IA: elige una categoría (explicar, guiar, solucionar o saltar), deja que el agente sugiera una corrección, y reintenta — todo sin salir de la terminal. Para configuraciones de infraestructura complejas, eso ahorra tiempo real.

Container App Jobs y mejoras de despliegue

Algunas funciones de despliegue que vale la pena mencionar:

Container App Jobs: azd ahora despliega Microsoft.App/jobs a través de la configuración existente host: containerapp. Tu plantilla Bicep determina si el destino es un Container App o un Job — sin configuración extra.
Timeouts configurables: Nueva flag --timeout en azd deploy y un campo deployTimeout en azure.yaml. Sin más adivinanzas sobre el límite predeterminado de 1200 segundos.
Fallback de build remoto: Cuando falla el build remoto en ACR, azd hace fallback automático a Docker/Podman local.
Validación preflight local: Los parámetros de Bicep se validan localmente antes de desplegar, detectando parámetros faltantes sin un viaje de ida y vuelta a Azure.

Pulido en la experiencia de desarrollador

Algunas mejoras más pequeñas que se suman:

Detección automática de pnpm/yarn para proyectos JS/TS
Soporte para pyproject.toml para paquetes Python
Directorios de plantillas locales — azd init --template ahora acepta rutas del sistema de archivos para iteración offline
Mejores mensajes de error en modo --no-prompt — todos los valores faltantes reportados de una vez con comandos de resolución
Variables de entorno de build inyectadas en todos los subprocesos de build (.NET, Node.js, Java, Python)

La última es sutil pero importante: tu build .NET ahora tiene acceso a las variables de entorno de azd, lo que significa que puedes hacer inyección de configuración en tiempo de compilación sin scripting adicional.

Para cerrar

El bucle de depuración local de agentes IA es la estrella de esta versión, pero la acumulación de mejoras de despliegue y refinamiento de DX hace que azd se sienta más maduro que nunca. Si estás desplegando apps .NET en Azure — especialmente agentes IA — esta actualización vale la pena.

Revisa las notas completas de la versión para todos los detalles, o comienza con la instalación de azd.

Del portátil a producción: desplegando agentes de IA en Microsoft Foundry con dos comandos

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

¿Conoces esa brecha entre “funciona en mi máquina” y “está desplegado y sirviendo tráfico”? Para agentes de IA, esa brecha ha sido dolorosamente amplia. Necesitas provisionar recursos, desplegar modelos, configurar identidad, montar monitoreo — y eso es antes de que alguien pueda realmente llamar a tu agente.

El Azure Developer CLI acaba de convertir esto en un asunto de dos comandos.

El nuevo flujo de trabajo `azd ai agent`

Déjame mostrarte cómo se ve esto realmente. Tienes un proyecto de agente de IA — digamos un agente concierge de hotel. Funciona localmente. Quieres que corra en Microsoft Foundry.

azd ai agent init
azd up

Eso es todo. Dos comandos. azd ai agent init genera la infraestructura como código en tu repositorio, y azd up provisiona todo en Azure y publica tu agente. Obtienes un enlace directo a tu agente en el portal de Foundry.

Qué pasa por debajo

El comando init genera plantillas Bicep reales e inspeccionables en tu repositorio:

Un Foundry Resource (contenedor de nivel superior)
Un Foundry Project (donde vive tu agente)
Configuración de despliegue de modelo (GPT-4o, etc.)
Identidad administrada con asignaciones de roles RBAC apropiadas
azure.yaml para el mapa de servicios
agent.yaml con metadatos del agente y variables de entorno

La parte clave: todo esto es tuyo. Es Bicep versionado en tu repositorio. Puedes inspeccionarlo, personalizarlo y hacer commit junto con el código de tu agente. Sin cajas negras mágicas.

El ciclo interno de desarrollo

Lo que realmente me gusta es la historia de desarrollo local. Cuando estás iterando sobre la lógica del agente, no quieres redesplegar cada vez que cambias un prompt:

azd ai agent run

Esto inicia tu agente localmente. Combínalo con azd ai agent invoke para enviar prompts de prueba, y tienes un ciclo de retroalimentación rápido. Editar código, reiniciar, invocar, repetir.

El comando invoke es inteligente con el enrutamiento también — cuando un agente local está corriendo, lo apunta automáticamente. Cuando no, apunta al endpoint remoto.

Monitoreo en tiempo real

Esta es la característica que me convenció. Una vez que tu agente está desplegado:

azd ai agent monitor --follow

Cada petición y respuesta que fluye a través de tu agente se transmite a tu terminal en tiempo real. Para depurar problemas en producción, esto es invaluable. Sin buscar en log analytics, sin esperar a que las métricas se agreguen — ves lo que está pasando ahora mismo.

El set completo de comandos

Aquí la referencia rápida:

Comando	Qué hace
`azd ai agent init`	Genera un proyecto de agente Foundry con IaC
`azd up`	Provisiona recursos Azure y despliega el agente
`azd ai agent invoke`	Envía prompts al agente remoto o local
`azd ai agent run`	Ejecuta el agente localmente para desarrollo
`azd ai agent monitor`	Transmite logs en tiempo real del agente publicado
`azd ai agent show`	Verifica la salud y estado del agente
`azd down`	Limpia todos los recursos Azure

Por qué esto importa para desarrolladores .NET

Aunque el ejemplo del anuncio está basado en Python, la historia de infraestructura es agnóstica al lenguaje. Tu agente .NET obtiene el mismo scaffolding Bicep, la misma configuración de identidad administrada, el mismo pipeline de monitoreo. Y si ya estás usando azd para tus apps .NET Aspire o despliegues Azure, esto encaja directamente en tu flujo de trabajo existente.

La brecha de despliegue para agentes de IA ha sido uno de los mayores puntos de fricción en el ecosistema. Pasar de un prototipo funcional a un endpoint de producción con identidad, networking y monitoreo adecuados no debería requerir una semana de trabajo DevOps. Ahora requiere dos comandos y unos minutos.

Para cerrar

azd ai agent está disponible ahora. Si has estado posponiendo el despliegue de tus agentes de IA porque la configuración de infraestructura parecía demasiado trabajo, dale una oportunidad. Revisa el tutorial completo para el paso a paso completo incluyendo integración de app de chat frontend.

Azd | The .NET Blog

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Hooks, brevemente, por si no los conoces

Cómo funciona la detección

Detalles importantes por lenguaje

Python

JavaScript y TypeScript

.NET

Config por ejecutor

Por qué importa para desarrolladores .NET

Conclusión

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

Configuración con Copilot durante azd init

Lo que hace realmente

Resolución de errores potenciada por Copilot

Ejemplos reales donde brilla

Configurar un comportamiento predeterminado

Por qué importa esto para los desarrolladores .NET

Conclusión

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Cómo funciona

El pequeño detalle

Por qué importa

azd ahora te permite ejecutar y depurar agentes IA localmente — Esto es lo que cambió en marzo 2026

Ejecutar y depurar agentes IA sin desplegar

GitHub Copilot configura tu proyecto azd

Container App Jobs y mejoras de despliegue

Pulido en la experiencia de desarrollador

Para cerrar

Del portátil a producción: desplegando agentes de IA en Microsoft Foundry con dos comandos

El nuevo flujo de trabajo azd ai agent

Qué pasa por debajo

El ciclo interno de desarrollo

Monitoreo en tiempo real

El set completo de comandos

Por qué esto importa para desarrolladores .NET

Para cerrar

El nuevo flujo de trabajo `azd ai agent`