Devops | The .NET Blog

Servidor Azure DevOps d'abril de 2026: correcció de finalització de relacions públiques i actualitzacions de seguretat

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

Informació ràpida per als equips que executen Azure DevOps Server: Microsoft va llançar el pegat 3 per a l’abril de 2026 amb tres solucions específiques.

Què s’ha solucionat

Errores de finalització de la sol·licitud d’extracció: una excepció de referència nul·la durant la compleció automàtica d’elements de treball podria provocar que les combinacions de PR fallin. Si heu trobat errors de finalització de PR aleatòries, és probable que aquesta sigui la causa
Validació de la redirecció de tancament de la sessió: validació millorada durant la tancament de la sessió per evitar possibles redireccions malicioses. Aquesta és una solució de seguretat que val la pena aplicar ràpidament
Connexions PAT del servidor GitHub Enterprise: la creació de connexions de testimoni d’accés personal al servidor GitHub Enterprise es va trencar, ara s’ha restaurat

Com actualitzar

Baixeu Pedaç 3 i executeu l’instal·lador. Per verificar que s’ha aplicat el pegat:

<patch-installer>.exe CheckInstall

Si esteu executant Azure DevOps Server localment, Microsoft us recomana fermament mantenir-vos en l’últim pedaç tant per seguretat com per fiabilitat. Consulteu les notes de la versió per a tots els detalls.

L'enginyeria de la plataforma agentica s'està tornant real: Git-APE mostra com

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

L’enginyeria de plataformes ha estat un d’aquells termes que sona molt bé a les conferències, però normalment significa “vam construir un portal intern i un embolcall de Terraform”. La veritable promesa: una infraestructura d’autoservei que és realment segura, governada i ràpida, sempre ha estat a pocs passos.

L’equip d’Azure acaba de publicar la Part 2 de la seva sèrie d’enginyeria de plataformes agents, i aquesta tracta sobre la implementació pràctica. L’anomenen Git-APE (sí, l’acrònim és intencionat) i és un projecte de codi obert que utilitza agents GitHub Copilot més servidors Azure MCP per convertir les sol·licituds de llenguatge natural en una infraestructura validada i desplegada.

Què fa realment Git-APE

La idea bàsica: en lloc que els desenvolupadors aprenguin mòduls de Terraform, naveguin per les interfícies d’usuari del portal o presenten entrades a un equip de plataforma, parlen amb un agent Copilot. L’agent interpreta la intenció, genera Infrastructure-as-Code, la valida amb polítiques i desplega, tot dins de VS Code.

Aquí teniu la configuració:

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

Obriu l’espai de treball a VS Code i GitHub Copilot descobreix automàticament els fitxers de configuració de l’agent. Interacciones directament amb l’agent:

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

L’agent utilitza Azure MCP Server sota el capó per interactuar amb els serveis d’Azure. La configuració de MCP a la configuració del codi VS permet capacitats específiques:

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

Per què això és important

Per a aquells que estem construint a Azure, això canvia la conversa sobre l’enginyeria de la plataforma de “com construïm un portal” a “com descriurem les nostres baranes com a API”. Quan la interfície de la vostra plataforma és un agent d’IA, la qualitat de les vostres limitacions i polítiques es converteix en el producte.

El bloc de la Part 1 va exposar la teoria: les API ben descrites, els esquemes de control i les baranes explícites fan que les plataformes estiguin preparades per a agents. La part 2 demostra que funciona enviant eines reals. L’agent no només genera recursos a cegues, sinó que valida les millors pràctiques, respecta les convencions de denominació i aplica les polítiques de la vostra organització.

La neteja és igual de fàcil:

@git-ape destroy my-resource-group

La meva opinió

Seré sincer: aquest tracta més del patró que de l’eina específica. El mateix Git-APE és una arquitectura de demostració/referència. Però la idea subjacent (agents com a interfície de la vostra plataforma, MCP com a protocol, GitHub Copilot com a amfitrió) és cap a on es dirigeix l’experiència dels desenvolupadors empresarials.

Si sou un equip de plataformes que mira com fer que els vostres agents d’eines internes siguin amigables, no hi ha millor punt de partida. I si sou un desenvolupador de.NET i us pregunteu com es connecta això amb el vostre món: els agents Azure MCP Server i GitHub Copilot funcionen amb qualsevol càrrega de treball d’Azure. La vostra API ASP.NET Core, la vostra pila.NET Aspire, els vostres microserveis en contenidors: tot això pot ser l’objectiu d’un flux de desplegament agent.

Tancant

Git-APE és una visió primerenca però concreta de l’enginyeria de plataformes agències a la pràctica. Cloneu el repo, proveu la demostració i comenceu a pensar com haurien de buscar un agent per utilitzar-los de manera segura les API i les polítiques de la vostra plataforma.

Llegiu la publicació completa per a la guia i les demostracions de vídeo.

Azure DevOps finalment soluciona l'UX de l'editor de Markdown de què es va queixar tothom

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

Si utilitzeu Azure Boards, probablement haureu experimentat això: esteu llegint la descripció d’un element de treball, potser revisant els criteris d’acceptació i accidentalment feu doble clic. Boom: esteu en mode d’edició. No volies editar res. Només estaves llegint.

Dan Hellem va anunciar la correcció, i és un d’aquests canvis que sona minúscul però que en realitat elimina la fricció real del vostre flux de treball diari.

Què va canviar

L’editor Markdown per als camps de text d’elements de treball ara s’obre en mode de vista prèvia de manera predeterminada. Podeu llegir i interactuar amb el contingut (seguir enllaços, revisar el format) sense preocupar-vos d’entrar accidentalment al mode d’edició.

Quan realment voleu editar, feu clic a la icona d’edició a la part superior del camp. Quan hàgiu acabat, torneu al mode de previsualització explícitament. Simple, intencionat, previsible.

Això és tot. Aquest és el canvi.

Per què això importa més del que sembla

El fil de comentaris de la comunitat sobre això era llarg. El comportament de fer doble clic per editar es va introduir amb l’editor Markdown el juliol de 2025 i les queixes van començar gairebé immediatament. El problema no eren només les edicions accidentals, sinó que tota la interacció semblava impredictible. Mai no sabíeu si fer clic es llegiria o editaria.

Per als equips que fan planificació d’esprints, preparació de backlog o revisió de codi amb Azure Boards, aquest tipus de compostos de microfricció. Cada entrada accidental del mode d’edició és un canvi de context. Cada “espera, he canviat alguna cosa?” moment és una atenció perduda.

El nou valor predeterminat respecta el patró d’interacció més comú: llegiu els elements de treball amb molta més freqüència que no els editeu.

Estat de llançament

Això ja s’està implementant a un subconjunt de clients i s’ampliarà a tothom durant les properes dues o tres setmanes. Si encara no ho veus, aviat ho faràs.

Tancant

No totes les millores han de ser una característica de titular. De vegades, la millor actualització és simplement eliminar alguna cosa molesta. Aquest és un d’ells: una petita correcció d’UX que fa que Azure Boards se senti menys hostil a les persones que només volen llegir els seus elements de treball amb tranquil·litat.

El servidor Azure DevOps MCP arriba a Microsoft Foundry: què significa això per als vostres agents d'IA

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

MCP (Model Context Protocol) ha tingut un moment. Si heu estat seguint l’ecosistema d’agents d’IA, probablement heu notat que els servidors MCP apareixen a tot arreu, donant als agents la possibilitat d’interaccionar amb eines i serveis externs mitjançant un protocol estandarditzat.

Ara el Servidor MCP d’Azure DevOps està disponible a Microsoft Foundry, i aquesta és una d’aquestes integracions que et fa pensar en les possibilitats pràctiques.

Què està passant realment aquí

Microsoft ja va llançar l’Azure DevOps MCP Server com a vista prèvia pública, això és el propi servidor MCP. La novetat és la integració de Foundry. Ara podeu afegir l’Azure DevOps MCP Server als vostres agents de Foundry directament des del catàleg d’eines.

Per a aquells que encara no estiguin familiaritzats amb Foundry: és la plataforma unificada de Microsoft per crear i gestionar aplicacions i agents basats en IA a escala. Accés al model, orquestració, avaluació, desplegament, tot en un sol lloc.

Configurant-lo

La configuració és sorprenentment senzilla:

Al vostre agent de Foundry, aneu a Afegeix eines > Catàleg
Cerqueu “Azure DevOps”
Seleccioneu el servidor Azure DevOps MCP (visualització prèvia) i feu clic a Crea
Introduïu el nom de la vostra organització i connecteu-vos

Això és tot. El vostre agent ara té accés a les eines d’Azure DevOps.

Controlar a què pot accedir el vostre agent

Aquesta és la part que agraeixo: no us enganxeu amb un enfocament de tot o res. Podeu especificar quines eines estan disponibles per al vostre agent. Per tant, si només voleu que llegeixi elements de treball però no toqui les canalitzacions, podeu configurar-ho. Principi de privilegis mínims, aplicat als vostres agents d’IA.

Això és important per als escenaris empresarials en què no voleu que un agent activi accidentalment una canalització de desplegament perquè algú li va demanar que “ajudés amb el llançament”.

Per què això és interessant per als equips.NET

Penseu en què permet això a la pràctica:

Ajudants de planificació de sprint: agents que poden extreure elements de treball, analitzar dades de velocitat i suggerir capacitat de sprint
Bots de revisió de codi: agents que entenen el vostre context de relacions públiques perquè poden llegir els vostres repositoris i els elements de treball enllaçats.
Resposta a incidents: agents que poden crear elements de treball, consultar implementacions recents i correlacionar errors amb canvis recents
Incorporació de desenvolupadors — “En què he de treballar?” obté una resposta real recolzada per dades reals del projecte

Per als equips.NET que ja utilitzen Azure DevOps per als seus pipelines CI/CD i la gestió de projectes, tenir un agent d’IA que pugui interactuar directament amb aquests sistemes és un pas important cap a una automatització útil (no només chatbot com a servei).

La imatge MCP més gran

Això forma part d’una tendència més àmplia: els servidors MCP s’estan convertint en la manera estàndard en què els agents d’IA interactuen amb el món exterior. Els veiem per a GitHub, Azure DevOps, bases de dades, API SaaS, i Foundry s’està convertint en el centre on s’uneixen totes aquestes connexions.

Si esteu creant agents a l’ecosistema.NET, val la pena prestar atenció a MCP. El protocol està estandarditzat, les eines estan madurant i la integració de Foundry el fa accessible sense haver de connectar manualment les connexions del servidor.

Tancant

El servidor Azure DevOps MCP a Foundry està en vista prèvia, així que espereu que evolucioni. Però el flux de treball bàsic és sòlid: connecteu-vos, configureu l’accés a les eines i deixeu que els vostres agents treballin amb les vostres dades de DevOps. Si ja sou a l’ecosistema de Foundry, això és a uns quants clics. Prova-ho i mira quins fluxos de treball pots crear.

Consulteu l’anunci complet per a la configuració pas a pas i més detalls.