Devops | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se celebra del 11 al 15 de mayo de 2026 en el Barbican Centre de Londres. La conferencia principal de 3 días es de martes a jueves, con talleres opcionales de día completo el lunes y el viernes.

Con 78 sesiones y 14 talleres, es una de las conferencias más completas para desarrolladores en Europa.

Temas

Pensamiento Arquitectónico
Código Funcional en C# 13
Diseño Serverless
IA Semántica
Azure Kubernetes Services
Estrategias Lean DevOps
The Model Context Protocol (MCP)
IA Agéntica en .NET
Refactorizando el Monolito
Programar Más Rápido con LLMs
Criptografía en un Mundo Post-Cuántico
Desarrollo Local First

Ponentes

Elenco de primer nivel incluyendo a Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm y Raju Gandhi.

Entradas e información

El 98% de los asistentes de SDD 2025 calificaron la experiencia general como buena, muy buena o excelente.

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.

Azure DevOps Server Parche Abril 2026 — Corrección en Completado de PRs y Actualizaciones de Seguridad

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

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

Aviso rápido para equipos que ejecutan Azure DevOps Server en sus propios servidores: Microsoft lanzó el Parche 3 de abril 2026 con tres correcciones específicas.

Qué se corrigió

Fallos en el completado de pull requests — una excepción de referencia nula durante el auto-completado de work items podía hacer que los merges de PRs fallaran. Si te topaste con errores aleatorios al completar PRs, esta es probablemente la causa
Validación en la redirección de cierre de sesión — se mejoró la validación durante el cierre de sesión para prevenir posibles redirecciones maliciosas. Esta es una corrección de seguridad que vale la pena aplicar pronto
Conexiones PAT con GitHub Enterprise Server — la creación de conexiones con Personal Access Token hacia GitHub Enterprise Server estaba rota, ahora se restauró

Cómo actualizar

Descarga el Parche 3 y ejecuta el instalador. Para verificar que el parche se aplicó:

<patch-installer>.exe CheckInstall

Si estás ejecutando Azure DevOps Server en tus propias instalaciones, Microsoft recomienda encarecidamente mantenerse en el último parche tanto por seguridad como por fiabilidad. Consulta las notas de la versión para todos los detalles.

La Ingeniería de Plataformas Agéntica Se Está Haciendo Real — Git-APE Muestra Cómo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

La ingeniería de plataformas ha sido uno de esos términos que suena genial en conferencias pero que normalmente significa “construimos un portal interno y un wrapper de Terraform.” La verdadera promesa — infraestructura self-service que realmente sea segura, gobernada y rápida — siempre ha estado a unos pasos de distancia.

El equipo de Azure acaba de publicar la Parte 2 de su serie sobre ingeniería de plataformas agéntica, y esta es sobre la implementación práctica. Lo llaman Git-APE (sí, el acrónimo es intencional), y es un proyecto open source que usa agentes de GitHub Copilot más servidores Azure MCP para convertir solicitudes en lenguaje natural en infraestructura validada y desplegada.

Qué hace Git-APE realmente

La idea central: en vez de que los desarrolladores aprendan módulos de Terraform, naveguen por UIs de portales o abran tickets al equipo de plataforma, hablan con un agente de Copilot. El agente interpreta la intención, genera Infrastructure-as-Code, la valida contra políticas y despliega — todo dentro de VS Code.

Aquí está la configuración:

git clone https://github.com/Azure/git-ape
cd git-ape

Abre el workspace en VS Code, y los archivos de configuración del agente son descubiertos automáticamente por GitHub Copilot. Interactúas con el agente directamente:

@git-ape deploy a function app with storage in West Europe

El agente usa Azure MCP Server internamente para interactuar con los servicios de Azure. La configuración de MCP en las opciones de VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por qué esto importa

Para los que construimos en Azure, esto cambia la conversación de ingeniería de plataformas de “cómo construimos un portal” a “cómo describimos nuestras barreras de seguridad como APIs.” Cuando la interfaz de tu plataforma es un agente de IA, la calidad de tus restricciones y políticas se convierte en el producto.

El blog de la Parte 1 planteó la teoría: APIs bien descritas, esquemas de control y barreras explícitas hacen las plataformas agent-ready. La Parte 2 lo demuestra funcionando con herramientas reales. El agente no genera recursos ciegamente — valida contra mejores prácticas, respeta convenciones de nomenclatura y aplica las políticas de tu organización.

La limpieza es igual de sencilla:

@git-ape destroy my-resource-group

Mi opinión

Seré honesto — esta es más sobre el patrón que sobre la herramienta específica. Git-APE en sí es una demo/arquitectura de referencia. Pero la idea subyacente — agentes como la interfaz de tu plataforma, MCP como protocolo, GitHub Copilot como host — es hacia donde se dirige la experiencia del desarrollador empresarial.

Si eres un equipo de plataforma buscando cómo hacer tu herramienta interna amigable para agentes, no hay mejor punto de partida. Y si eres un desarrollador .NET preguntándote cómo se conecta esto con tu mundo: el Azure MCP Server y los agentes de GitHub Copilot funcionan con cualquier carga de trabajo de Azure. Tu API ASP.NET Core, tu stack .NET Aspire, tus microservicios contenerizados — todo puede ser el objetivo de un flujo de despliegue agéntico.

Para cerrar

Git-APE es una mirada temprana pero concreta a la ingeniería de plataformas agéntica en la práctica. Clona el repo, prueba la demo y empieza a pensar en cómo las APIs y políticas de tu plataforma necesitarían verse para que un agente las use de forma segura.

Lee el post completo para el walkthrough y videos de demostración.

Azure DevOps por fin arregla el editor Markdown que todos odiaban

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

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

Si usas Azure Boards, probablemente has vivido esto: estás leyendo la descripción de un work item, tal vez revisando los criterios de aceptación, y accidentalmente haces doble clic. Boom — estás en modo edición. No querías editar nada. Solo estabas leyendo.

Dan Hellem anunció la corrección, y es uno de esos cambios que suenan pequeños pero realmente eliminan fricción de tu flujo de trabajo diario.

Qué cambió

El editor Markdown para campos de texto de work items ahora abre en modo vista previa por defecto. Puedes leer e interactuar con el contenido — seguir enlaces, revisar formato — sin preocuparte por entrar accidentalmente en modo edición.

Cuando realmente quieres editar, haces clic en el ícono de edición en la parte superior del campo. Cuando terminas, sales explícitamente al modo vista previa. Simple, intencional, predecible.

Eso es. Ese es el cambio.

Por qué importa más de lo que parece

El hilo de feedback de la comunidad sobre esto era largo. El comportamiento de doble clic para editar se introdujo con el editor Markdown en julio 2025, y las quejas empezaron casi inmediatamente. El problema no eran solo las ediciones accidentales — era que toda la interacción se sentía impredecible.

Para equipos que hacen planificación de sprints, refinamiento de backlog o revisión de código con Azure Boards, este tipo de micro-fricción se acumula. Cada entrada accidental al modo edición es un cambio de contexto. Cada momento de “espera, ¿cambié algo?” es atención desperdiciada.

Estado del despliegue

Ya se está implementando para un subconjunto de clientes y se expandirá a todos en las próximas dos o tres semanas.

Para cerrar

No toda mejora necesita ser una función titular. A veces la mejor actualización es simplemente eliminar algo molesto. Esta es una de esas — una pequeña corrección de UX que hace que Azure Boards se sienta menos hostil para las personas que solo quieren leer sus work items en paz.

El MCP Server de Azure DevOps llega a Microsoft Foundry: Qué significa para tus agentes de IA

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

MCP (Model Context Protocol) está teniendo su momento. Si has estado siguiendo el ecosistema de agentes de IA, probablemente hayas notado que los servidores MCP están apareciendo por todas partes — dándoles a los agentes la capacidad de interactuar con herramientas y servicios externos a través de un protocolo estandarizado.

Ahora el MCP Server de Azure DevOps está disponible en Microsoft Foundry, y esta es una de esas integraciones que te hace pensar en las posibilidades prácticas.

Qué está pasando realmente aquí

Microsoft ya lanzó el MCP Server de Azure DevOps como public preview — ese es el servidor MCP en sí. Lo nuevo es la integración con Foundry. Ahora puedes agregar el MCP Server de Azure DevOps a tus agentes de Foundry directamente desde el catálogo de herramientas.

Para los que no están familiarizados con Foundry todavía: es la plataforma unificada de Microsoft para construir y gestionar aplicaciones y agentes impulsados por IA a escala. Acceso a modelos, orquestación, evaluación, despliegue — todo en un solo lugar.

Configurándolo

La configuración es sorprendentemente sencilla:

En tu agente de Foundry, ve a Add Tools > Catalog
Busca “Azure DevOps”
Selecciona el Azure DevOps MCP Server (preview) y haz clic en Create
Ingresa el nombre de tu organización y conecta

Eso es todo. Tu agente ahora tiene acceso a las herramientas de Azure DevOps.

Controlando a qué puede acceder tu agente

Esta es la parte que aprecio: no estás atrapado con un enfoque de todo o nada. Puedes especificar qué herramientas están disponibles para tu agente. Así que si solo quieres que lea work items pero no toque pipelines, puedes configurar eso. Principio de mínimo privilegio, aplicado a tus agentes de IA.

Esto importa para escenarios empresariales donde no quieres que un agente accidentalmente dispare un pipeline de despliegue porque alguien le pidió que “ayude con el release.”

Por qué esto es interesante para equipos .NET

Piensa en lo que esto habilita en la práctica:

Asistentes de planificación de sprint — agentes que pueden obtener work items, analizar datos de velocidad y sugerir capacidad de sprint
Bots de code review — agentes que entienden el contexto de tu PR porque realmente pueden leer tus repos y work items vinculados
Respuesta a incidentes — agentes que pueden crear work items, consultar despliegues recientes y correlacionar bugs con cambios recientes
Onboarding de desarrolladores — “¿En qué debería trabajar?” obtiene una respuesta real respaldada por datos reales del proyecto

Para equipos .NET que ya usan Azure DevOps para sus pipelines de CI/CD y gestión de proyectos, tener un agente de IA que pueda interactuar directamente con esos sistemas es un paso significativo hacia la automatización útil (no solo chatbot-como-servicio).

El panorama más amplio de MCP

Esto es parte de una tendencia más amplia: los servidores MCP se están convirtiendo en la forma estándar en que los agentes de IA interactúan con el mundo exterior. Los estamos viendo para GitHub, Azure DevOps, bases de datos, APIs SaaS — y Foundry se está convirtiendo en el hub donde todas estas conexiones se unen.

Si estás construyendo agentes en el ecosistema .NET, vale la pena prestar atención a MCP. El protocolo está estandarizado, las herramientas están madurando, y la integración con Foundry lo hace accesible sin tener que conectar manualmente las conexiones del servidor.

Para cerrar

El MCP Server de Azure DevOps en Foundry está en preview, así que espera que evolucione. Pero el flujo de trabajo principal es sólido: conectar, configurar acceso a herramientas, y dejar que tus agentes trabajen con tus datos de DevOps. Si ya estás en el ecosistema de Foundry, esto está a unos pocos clics. Dale una oportunidad y ve qué flujos de trabajo puedes construir.

Revisa el anuncio completo para la configuración paso a paso y más detalles.