Developer Experience | The .NET Blog

Revisar pull requests dins de Visual Studio és exactament el tipus de reducció de fricció que m'agrada

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Aquest article s’ha traduït automàticament. L’original és aquí.

El navegador ha estat robant massa part del flux de treball de code review durant massa temps.

Per això em fa molta il·lusió veure Visual Studio avançar encara més cap a la revisió de pull requests de principi a fi dins de l’IDE.

Aquesta és una d’aquelles funcions que pot no generar grans titulars, però que pot millorar molt el desenvolupament quotidià.

El valor principal és simple: menys canvi de context

Quan el teu bucle de review viu parcialment dins de l’IDE i parcialment al navegador, la fricció s’acumula:

obre el PR en un altre lloc
inspecciona els canvis en una eina
torna a la solució per investigar més a fons
canvia una altra vegada per comentar o aprovar

No és catastròfic. Només és ineficient.

Si Visual Studio et permet obrir, inspeccionar, comentar, aprovar i fer merge des del mateix entorn de treball, això és un guany de productivitat real.

L’opció de “review sense checkout” és especialment bona

Una part que m’agrada especialment és poder revisar sense fer checkout de la branca del PR.

Pot semblar petit, però és perfecte per a:

passades ràpides de review
sol·licituds de feedback interrompudes
mantenir intactes la branca actual i l’estat local

Això és exactament el tipus de flexibilitat que necessiten les bones eines de code review.

La meva opinió

Això no és una funció revolucionària.

És una cosa millor: una funció pràctica.

Per als equips que passen la major part del dia a Visual Studio, un suport més estret per al review de PR significa menys interrupcions del flux de treball i un camí més suau de la inspecció a l’acció.

És una millora que val la pena, al meu parer.

Publicació original: Revisa pull requests sense sortir de Visual Studio

Els Agent Harnesses Importen Perquè els Prompts No Són Suficients

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

Un dels errors més fàcils en el desenvolupament d’agents és pensar que el prompt és el producte.

No ho és.

El nou tutorial sobre agent harness i claw de l’equip de Microsoft Agent Framework és valuós perquè manté l’enfocament en la part que realment determina si un agent se sent utilitzable: el shell d’execució al voltant del model.

Això inclou:

eines
planificació
estat de sessió
memòria
modes d’execució
una consola o interfície utilitzable per a la iteració

L’article acompanya la implementació completa d’un agent de codificació autònom que opera des d’un contenidor Docker amb accés al sistema de fitxers, execució d’ordres i un bucle autònom sense intervenció humana. No és una abstracció teòrica: és el claw executant-se realment.

Per què el claw és diferent

Si has seguit el projecte Semaphore de Microsoft Research, el claw et resultarà familiar. És un entorn on un agent pot:

inspeccionar directoris i fitxers
llegir i escriure fitxers
executar ordres de shell
processar la sortida i continuar iterant

La versió de Microsoft Agent Framework s’integra directament amb el claw: us permet executar un agent autònom configurat amb prompt i opcions dins d’un contenidor aïllat. El resultat és un patró repetible: contenidor → claw → agent. Sense dependències estranyes. Sense eines de compilació personalitzades.

Per què això importa als desenvolupadors de .NET

El claw demostra alguna cosa que no es pot aconseguir només amb prompts: comportament autònom en bucle tancat sobre dades i sistemes reals.

Un agent de codificació que pot escriure un fitxer, executar proves i iterar sobre els resultats sense que un humà li passi cada fragment de text és qualitativament diferent d’un xat LLM al qual demanes que generi codi.

La diferència és la propietat del bucle tancat. Qui decideix què provar a continuació? Qui gestiona l’estat entre passos? Un harness fa que l’agent sigui propietari del bucle. Un prompt deixa el bucle a les mans de l’usuari.

On aniria amb compte

No obstant això, el claw no és per a tot. L’execució autònoma en un bucle és potent, però també és una àrea on el cost i la correcció necessiten supervisió externa. És per això que l’article recomana executar el claw en un contenidor: conté el radi d’explosió.

Per a escenaris de baixa autonomia on les eines són simples i les interaccions són breus, un agent senzill amb un prompt ben escrit pot ser suficient.

El punt no és que el claw substitueixi tota conversa. El punt és que el ventall d’arquitectures d’agents que pots construir és més ampli del que permets si només penses en termes de model + prompt.

Publicació original: Introducing agent harness and claw for the Microsoft Agent Framework

Aspire a VS Code 13.4 Ajusta el Bucle de Desenvolupament en Totes les Direccions Correctes

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

Les millors actualitzacions d’eines són les que notes després d’uns dies, no les que només queden bé a les notes de versió.

Així és com llegeixo Aspire a VS Code 13.4.

Aquesta actualització tracta d’ajustar el bucle intern: crear projectes més ràpid, depurar aplicacions de llenguatge mixt de manera més natural, mostrar salut i ordres directament a l’editor, i mantenir el dashboard a prop sense fer-lo l’únic lloc on pots treballar.

Aquesta és una molt bona direcció.

El gran guany és menys canvi de context

Si utilitzes Aspire seriosament, normalment et mous entre diverses superfícies:

codi AppHost
terminal
dashboard
logs
sessions de depuració
endpoints de servei

El que 13.4 fa bé és reduir la fricció entre aquestes superfícies.

La nova experiència de VS Code fa que més de l’estat de l’aplicació sigui visible exactament on ja estàs treballant:

salut dels recursos a l’editor
ordres al costat de les declaracions de recursos
accés més fàcil al dashboard
accés als logs des del context d’AppHost
un panell que segueix sent útil fins i tot abans que comenci la depuració completa

Això sona petit fins que ho fas cada dia.

Depurar stacks mixtos importa més del que la gent pensa

Una de les parts més sòlides d’aquesta actualització és la història més natural per depurar C#, TypeScript, Python, Go, aplicacions de navegador i Azure Functions en un sol flux impulsat per Aspire.

Això reflecteix la forma real de les aplicacions modernes molt millor que pretendre que tot viu en un sol runtime.

Per als desenvolupadors .NET especialment, això és valuós perquè molts de nosaltres ara estem construint sistemes que barregen projectes API, frontends, workers i serveis adjacents a IA en diferents llenguatges.

El fet que Aspire estigui fent que això se senti més unificat dins de VS Code és una millora molt pràctica.

El suport per a TypeScript AppHost arribant a GA també és significatiu

No ignoraria la banda de TypeScript AppHost d’aquest llançament.

Aspire tornant-se més natural tant per a C# com per a TypeScript amplia qui pot treballar al mateix model de sistema sense fluxos de treball estranys de segona classe. Això importa per a equips on el codi de plataforma, el codi de frontend i l’orquestració de serveis viuen molt a prop.

La meva opinió

Aspire 13.4 a VS Code no va d’una característica estrella. Va de suavitzar les arestes del bucle diari:

començar més ràpid
veure més estat on escrius codi
depurar de manera més natural
saltar als logs i al dashboard només quan cal

Així és exactament com hauria d’evolucionar una bona eina.

Si ja utilitzes Aspire, aquesta actualització val la pena instal·lar-la. Si encara et preguntes si VS Code és una llar seriosa per al desenvolupament basat en Aspire, la resposta és cada cop més òbvia.

Article original: Aspire in VS Code: the 13.4 developer loop

El nou Plan agent de Visual Studio resol un problema molt real del flux de treball d'IA

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

Aquest article s’ha traduït automàticament. L’original és aquí.

Un dels fluxos de treball més frustrants de programació amb IA és quan la implementació comença massa de pressa.

El codi fins i tot pot ser tècnicament correcte, però resol la versió equivocada del problema que tenies al cap.

Volies una refactorització. Va començar una reescriptura. Volies una millora acotada. Va tocar mitja aplicació. Volies parlar de les opcions. Va saltar directament als canvis de fitxer.

Per això el nou Plan agent de Visual Studio és una addició tan útil.

Això resol un problema real de flux de treball, no només un problema estètic

La publicació original descriu una situació molt familiar: “El codi no està malament… simplement no és el que volies.”

Aquesta frase és perfecta.

Perquè el punt feble de molta feina assistida per IA no és si el model pot produir codi. És si el flux de treball crea prou espai per acordar la forma desitjada de la feina abans de començar la implementació.

Això és especialment important per a:

funcions grans
bases de codi desconegudes
refactoritzacions no trivials
canvis sensibles a l’arquitectura
feina que necessita revisió de l’equip abans de començar a editar

En aquestes situacions, anar directament a implementar sovint és el moviment equivocat.

Planificar no és sobrecàrrega quan la tasca és real

Crec que de vegades els equips subestimen quant temps perden quan comencen a implementar massa aviat.

Si l’agent:

toca els fitxers equivocats
tria l’enfocament equivocat
passa per alt una restricció clau
ignora un cas límit necessari

llavors el començament “ràpid” acaba sent un flux de treball més lent en conjunt.

Per això m’agrada aquesta funció.

Fa espai per a:

preguntes de clarificació
redacció del pla
edició directa del pla
compartir el pla abans que comencin els canvis de codi

Això no és burocràcia. Sovint és simplement bona enginyeria.

El fitxer de pla en markdown és una tria intel·ligent

Un detall que m’agrada especialment és que cada pla es desa a .copilot/plans/plan-{title}.md.

Això fa que el pas de planificació sigui tangible.

Vol dir que el pla no queda atrapat dins d’un fil de conversa. Es converteix en una cosa que pots:

revisar
editar
versionar mentalment
discutir amb l’equip
passar a la implementació de manera més deliberada

Això fa que la funció sembli molt més seriosa que un simple preàmbul temporal abans de generar codi.

Aquí és on els fluxos d’IA comencen a respectar el procés de l’equip

Crec que aquest és un dels senyals més forts que aquestes eines estan madurant.

Els millors fluxos d’IA per a desenvolupadors no són els que eliminen tots els passos intermedis. Són els que milloren els passos intermedis adequats.

I la planificació és un d’aquests passos.

Si el pla és fort, implementar és més fàcil. Si el pla és feble, la implementació es torna sorollosa.

Aquesta funció ho reconeix directament.

La meva opinió

Això no és només una simplicitat d’IA.

És una millora del flux de treball.

I per a funcions reals i refactoritzacions reals, és exactament el tipus de millora que pot estalviar molt de churn innecessari, soroll de revisió i rework del tipus “això no és el que volia dir”.

Crec que cada vegada més experiències d’agents acabaran necessitant una cosa així.

Visual Studio hi ha arribat abans d’una manera que se sent útil.

Publicació original: Planifica abans de construir: presentem el Plan agent a Visual Studio

El teu dev loop és ple de coneixement tribal, i Aspire hi respon encertadament

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Aquest article s’ha traduït automàticament. L’original és aquí.

Aquest pot ser un dels articles més importants d’Aspire per entendre per què importa el producte.

No perquè anunciï una gran funcionalitat nova.

Sinó perquè posa nom a un problema que gairebé tots els equips d’enginyeria han sentit, i no tots han sabut descriure bé:

el dev loop és ple de coneixement tribal.

Aquesta frase encaixa perquè és certa.

El problema no és la manca d’eines

L’argument central de l’article original és excel·lent: sovint els equips no pateixen manca d’infraestructura, scripts, dashboards o ordres.

El que els falta és un model coherent que converteixi tot el coneixement operatiu ocult al voltant de l’aplicació en alguna cosa visible i repetible.

L’arquitectura real de moltes apps viu en:

l’historial del shell
scripts dispersos
fragments del README
fils de Slack
l’únic enginyer sènior que coneix l’ordre de les operacions

Això no és un dev loop sostenible per a humans.

I definitivament tampoc ho és per a agents.

La cita que crec que captura tot el post

Hi ha una frase a l’article original que crec que capta molt bé el punt general:

“Les aplicacions ja existeixen com a sistemes. Aspire fa explícits aquests sistemes, perquè els sistemes explícits escalen millor que el coneixement tribal.”

Això és tota la tesi en una sola línia.

I sincerament, és una de les millors explicacions d’una sola frase sobre Aspire que he vist fins ara.

Per què això importa més ara que fa un any

Crec que aquest article encaixa especialment bé en el moment actual perquè el desenvolupament assistit per IA canvia el cost de l’ambigüitat.

Els humans poden compensar sistemes incomplets sorprenentment bé.

Recordem:

quin script cal executar primer
quin environment variable es necessita de forma amagada
quina terminal mostra normalment els logs útils
quin servei cal reiniciar dues vegades per raons que ningú no va documentar

Els agents són molt pitjors amb aquest tipus de folklore operatiu ocult.

Per això, si volem que els agents esdevinguin realment útils en repositoris reals, hem de fer el sistema més explícit, no menys.

Per això crec que el marc d’Aspire és important.

El valor real d’Aspire no és només l’orquestració

Un error comú és pensar en Aspire només com un llançador d’apps distribuïdes o un ajudant d’orquestració local.

Això és una visió massa petita.

El valor més fort és que Aspire dona a l’aplicació:

un model
una forma
recursos amb nom
dependències explícites
superfícies de salut i operacions
ordres que humans i automatització poden entendre

Això canvia el dev loop més del que de vegades la gent s’adona.

Perquè un cop l’app deixa de ser una pila de convencions implícites i passa a ser un sistema amb un model real, diverses coses es fan més fàcils alhora:

onboarding
debugging
setup repetible
coherència en CI
fluxos de treball assistits per IA

Això és molta palanca a partir d’una sola decisió de disseny.

M’agrada especialment l’angle de “comandes com a operacions de primera classe”

Un altre punt de l’article original que crec que mereix més atenció és el pas de les instruccions al README cap a ordres associades a recursos.

És un canvi aparentment petit però molt gran.

En lloc de dir:

executa aquest script, després aquell altre, i potser aquest altre si falla el primer

pots modelar les operacions directament dins del context de l’app.

Això fa que els humans les puguin descobrir més fàcilment.

I fa que els agents no hagin d’endevinar la intenció a partir de prosa.

Això és el que converteix una aplicació de “operable si ja la coneixes” a “operable per disseny”.

Què en trauria com a responsable d’equip

Si mirés el dev loop del meu equip des d’aquest angle, em faria unes quantes preguntes molt directes:

fins a quin punt el nostre setup depèn de la memòria?
quantes accions de desenvolupament crítiques només existeixen a la documentació o als fils de xat?
amb quina freqüència els nous contributors queden bloquejats per comportament invisible del sistema?
podria una eina d’automatització o un coding agent entendre la topologia de la nostra app només des del repo?

Si la resposta a l’última pregunta és “ni de bon tros”, aquest article hauria de tocar una fibra útil.

La meva opinió

Aquesta és una formulació molt forta del valor real d’Aspire.

No és només orquestració.

És fer que el model de l’app sigui prou explícit perquè el sistema sigui més fàcil d’operar, entendre i automatitzar.

Això importa per a les persones. Importa per als equips. I encara importa més ara que tanta part del desenvolupament modern es mou cap a fluxos assistits per agents.

És exactament el tipus d’article que ajuda a explicar per què Aspire se sent cada cop més rellevant més enllà de l’etiqueta de màrqueting de .NET.

Publicació original: El teu dev loop és ple de coneixement tribal— title: “El teu dev loop és ple de coneixement implícit, i Aspire té la resposta adequada” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Una nova publicació d’Aspire fa un punt molt sòlid: molts equips no tenen un problema de tooling, sinó un model d’aplicació coherent que converteix el coneixement operatiu ocult en una cosa que humans, scripts i agents poden fer servir de veritat.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

Aquest article s’ha traduït automàticament. L’original és aquí.

Potser aquesta és una de les publicacions més importants d’Aspire per entendre per què el producte importa.

No perquè anunciï una funció enorme nova.

Perquè posa nom a un problema que gairebé tots els equips d’enginyeria han sentit i no tots han sabut descriure bé:

el dev loop és ple de coneixement implícit.

Aquesta frase impacta perquè és certa.

El problema no és la manca d’eines

L’argument central de l’article original és excel·lent: els equips sovint no pateixen manca d’infraestructura, scripts, taulers o comandos.

El que els falta és un model coherent que converteixi tot el coneixement operatiu ocult al voltant de l’aplicació en una cosa visible i repetible.

L’arquitectura real de moltes apps viu en:

l’historial del shell
scripts dispersos
fragments de README
fils de Slack
aquell enginyer sènior que sap l’ordre exacte de les operacions

Això no és un dev loop sostenible per a humans.

I definitivament tampoc per a agents.

La cita que, crec, captura tot el post

Hi ha una frase de l’article original que crec que captura molt bé la idea general:

“Les aplicacions ja existeixen com a sistemes. Aspire fa explícits aquests sistemes, perquè els sistemes explícits escalen millor que el coneixement implícit.”

Aquesta és tota l’argumentació en una sola línia.

I sincerament, és una de les millors explicacions d’una sola frase d’Aspire que he vist fins ara.

Per què això importa més ara que fa un any

Crec que aquesta publicació funciona especialment bé ara perquè el desenvolupament assistit per IA canvia el cost de l’ambigüitat.

Els humans poden compensar sistemes incomplets sorprenentment bé.

Recordem:

quin script s’ha d’executar primer
quina variable d’entorn és necessària en secret
quina terminal sol mostrar els logs útils
quin servei s’ha de reiniciar dues vegades per raons que ningú no ha documentat

Els agents són molt pitjors en aquest tipus de folklore operatiu ocult.

Per això, si volem que els agents siguin realment útils en repositoris reals, hem de fer que el sistema sigui més explícit, no menys.

Per això crec que aquest marc d’Aspire és important.

El valor real d’Aspire no és només l’orquestració

Un error habitual amb Aspire és pensar-hi només com en un llançador d’aplicacions distribuïdes o un ajudant d’orquestració local.

Això és massa petit.

La proposta de valor més forta és que Aspire dona a l’aplicació:

un model
una forma
recursos amb nom
dependències explícites
superfícies de salut i operacions
comandaments que humans i automatització poden entendre

Això canvia el dev loop més del que a vegades sembla.

Perquè, quan l’app deixa de ser una pila de convencions implícites i passa a ser un sistema amb un model real, diverses coses es tornen més fàcils alhora:

onboarding
debugging
configuració repetible
coherència de CI
fluxos de treball assistits per IA

És molta palanca a partir d’una sola decisió de disseny.

M’agrada especialment l’angle de “comandes com a operacions de primera classe”

Un altre punt del post original que crec que mereix més atenció és el pas d’instruccions README a comandes associades a recursos.

És un canvi enganyosament gran.

En lloc de dir:

executa aquest script, després aquell, i potser aquest altre si falla el primer

pots modelar les operacions directament dins del context de l’app.

Això vol dir que els humans les poden descobrir més fàcilment.

I vol dir que els agents no han d’endevinar la intenció a partir de prosa.

Això és el tipus de cosa que converteix una aplicació de “operable si ja la coneixes” a “operable per disseny”.

Què en trauria jo com a team lead

Si mirés el dev loop del meu equip a través d’aquest prisma, em faria algunes preguntes directes:

quina part de la nostra configuració depèn de la memòria?
quantes accions crítiques de desenvolupament només existeixen en docs o fils de xat?
amb quina freqüència els nous contribuïdors queden bloquejats per un comportament invisible del sistema?
podria una eina d’automatització o un coding agent entendre la topologia de l’app només a partir del repo?

Si la resposta a aquesta última és “ni de lluny”, aquesta publicació hauria de tocar una fibra útil.

La meva opinió

Aquesta és una manera molt forta d’explicar el valor real d’Aspire.

No és només orquestració.

És fer que el model de l’app sigui prou explícit perquè el sistema sigui més fàcil d’operar, entendre i automatitzar.

Això importa per a les persones. Importa per als equips. I importa encara més ara que tanta part del desenvolupament modern es mou cap a fluxos de treball assistits per agents.

Aquesta és exactament la mena d’article que ajuda a explicar per què Aspire sembla cada vegada més rellevant més enllà de l’etiqueta de màrqueting de .NET.

Publicació original: El teu dev loop és ple de coneixement implícit

Les proves d’extrem a extrem hermètiques d’Aspire són un patró que més equips haurien d’adoptar

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Aquest article ha estat traduït automàticament. Per a la versió original, fes clic aquí.

Les proves d’extrem a extrem inestables són cares d’una manera que no sempre apareix en un tauler.

No només fallen. També entrenen a poc a poc l’equip perquè deixi de confiar en el bucle de feedback.

Per això aquest article sobre Azure Chaos Studio + Aspire em va cridar l’atenció de seguida. No és un anunci de producte cridaner. És una història d’enginyeria molt concreta sobre com fer que les proves d’extrem a extrem deixin de semblar una negociació amb la sort.

I, sincerament, crec que més equips haurien d’adoptar aquest patró.

La idea central és senzilla, però el benefici és enorme

La clau és donar a cada prova el seu propi entorn hermètic i efímer amb serveis reals, dependències reals i un inici explícit basat en la salut.

Això sembla obvi quan ho llegeixes en una sola frase. En sistemes reals és molt més difícil, sobretot quan hi entren dependències al núvol, entorns compartits i serveis distribuïts.

L’article original explica el problema amb molta claredat: els entorns de prova compartits porten “cross-talk, la flakiness i els missatges de grup del tipus ‘qui ha trencat staging?’” com a cost de fer negocis.

Aquesta frase fa gràcia perquè fa mal.

Massa equips accepten aquest intercanvi com una cosa normal. Jo no crec que ho hagin de fer.

Per què aquest patró importa més enllà de les proves

El que més m’agrada aquí és que l’article no es limita a dir: “hem fet que les proves siguin més fiables”.

En realitat està dient una cosa més gran:

si el teu sistema distribuït és difícil de reproduir, difícil d’aïllar i difícil de verificar, tot el teu bucle d’enginyeria s’alenteix.

Això afecta més coses que la CI.

Afecta:

la confiança amb què els desenvolupadors fan refactors
la rapidesa amb què es diagnostiquen les regressions
com de segur és intentar canvis arquitectònics més grans
la confiança que l’equip posa en la validació automatitzada

I el 2026 també afecta com de útil pot arribar a ser el desenvolupament assistit per IA.

La cita més important de la publicació

Hi ha una línia de l’article que crec que val la pena repetir:

“Els agents no han de ser perfectes. Han de ser verificables.”

Aquest és un enfocament excel·lent.

La gent passa molt de temps preguntant-se si els agents de codi amb IA són prou fiables per ajudar en feina no trivial. Jo crec que la millor pregunta és si els nostres sistemes són prou testeables per jutjar aquesta feina correctament.

Si un agent proposa un refactor rellevant i el teu únic senyal de seguretat és un munt de comprovacions end-to-end fràgils i semi-aleatòries que s’executen en un entorn compartit, llavors el problema no és només l’agent.

El problema és el teu model de validació.

Aquest patró d’Aspire ho millora de manera espectacular.

Què fa especialment bona aquesta implementació

Diverses parts de la història original fan que això sigui molt més que una entrada vaga de “hem millorat les proves”.

1. Un graf de serveis real, no teatre de falsos mocks

Les proves no es construeixen sobre un munt de mocks desconnectats que fingeixen ser validació end-to-end.

Executen els binàries reals, connecten emuladors quan es pot i fan servir el mateix model d’aplicació que s’utilitza per al desenvolupament local.

Això importa.

Perquè, en el moment que les proves end-to-end es converteixen en teatre de mock contra mock, deixen de dir-te res de fiable sobre la composició real.

2. Arrencada basada en la salut en lloc de sleeps màgics

Aquest punt és més gran del que sembla.

L’article deixa clar que les proves esperen la salut real amb WaitForResourceHealthyAsync, en lloc de confiar en estimacions arbitràries de temps.

La diferència és enorme.

Una suite que diu “dorm 30 segons i creua els dits” està documentant incertesa. Una suite que espera la disponibilitat real està documentant la intenció del sistema.

3. El mateix model impulsa el desenvolupament local i les proves

Això m’agrada molt perquè encaixa amb les millors històries d’Aspire en general.

El mateix model d’aplicació impulsa:

el desenvolupament local
el cablejat dels serveis
les dependències emulades
les comprovacions de salut
l’orquestració de proves hermètiques

Això redueix la deriva, i la deriva és un dels assassins silenciosos de la confiança.

Aquest tipus d’inversió en experiència de desenvolupador se subestima

Una de les raons per les quals volia que aquesta entrada fos més llarga que una reacció ràpida és que crec que aquest tipus de millores d’enginyeria sovint es subestimen.

No són lluïdes.

No es demostren com una nova funció d’IA.

Tampoc no sempre produeixen una única diapositiva que entusiasmi els executius.

Però amb el temps creen una cosa molt més valuosa: un equip que pot avançar més ràpid sense mentir-se sobre la qualitat.

Això és importantíssim.

L’article diu que ara executen uns 90 tests hermètics, incloent-hi escenaris com fallades de zona, fallades de DNS i fallades de replicació geogràfica. Això no és només millor higiene de proves. És un model de confiança molt més fort per a una plataforma distribuïda.

Què en trauria jo si gestionés un sistema .NET distribuït

Si avui treballeu amb serveis distribuïts, Aspire i pipelines de CI/CD, això és el que en trauria de seguida:

deixeu de normalitzar la inestabilitat dels entorns compartits
aneu cap a portes d’inici basades en la salut sempre que pugueu
tracteu AppHost com a codi real d’orquestració de nivell producció
construïu comprovacions end-to-end que validin la composició dels serveis, no només la correcció de cada servei per separat
si adopteu el desenvolupament assistit per IA, invertiu primer en verificabilitat abans de perseguir més amplitud d’automatització

Aquest últim punt és el que crec que més equips han d’escoltar.

La meva opinió

Aquesta és una de les entrades d’Aspire més sòlides d’aquest lot perquè resol un problema molt pràctic.

No intenta impressionar-vos amb abstracció. Mostra com fer que les proves end-to-end siguin més deterministes, més útils i més fiables en un sistema distribuït real.

I, tan bon punt hi veus la connexió amb el desenvolupament assistit per agents, el patró encara es fa més convincent.

Si la vostra història de proves end-to-end encara depèn d’entorns compartits, coneixement ocult de configuració i una mica de pregària, val molt la pena estudiar-ho.

Article original: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests