Developer Experience | The .NET Blog

Pull requests reviewen in Visual Studio is precies het soort frictieverlaging dat ik prettig vind

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

Dit artikel is automatisch vertaald. Lees het origineel hier.

De browser heeft al veel te lang te veel van de code review-workflow overgenomen.

Daarom ben ik erg blij om te zien dat Visual Studio verder gaat met end-to-end pull request review binnen de IDE.

Dit is zo’n functie die misschien geen grote krantenkoppen oplevert, maar die de dagelijkse ontwikkeling absoluut kan verbeteren.

De belangrijkste waarde is simpel: minder context switching

Wanneer je review-loop deels in de IDE en deels in de browser leeft, stapelt de frictie zich op:

open de PR ergens anders
inspecteer de wijzigingen in één tool
ga terug naar de solution voor dieper onderzoek
switch nog eens om te reageren of goed te keuren

Dat is niet rampzalig. Het is gewoon inefficiënt.

Als Visual Studio je laat openen, inspecteren, commenten, approven en mergen vanuit dezelfde werkomgeving, dan is dat een echte productiviteitswinst.

De optie om te reviewen zonder checkout is extra fijn

Een deel dat ik bijzonder prettig vind, is de mogelijkheid om te reviewen zonder de PR-branch te checken.

Dat klinkt klein, maar is perfect voor:

snelle reviewrondes
feedbackverzoeken tijdens onderbrekingen
je huidige branch en lokale staat intact houden

Dat is precies het soort flexibiliteit dat goede code review-tools nodig hebben.

Mijn mening

Dit is geen revolutionaire functie.

Het is iets beters: iets praktisch.

Voor teams die het grootste deel van hun dag in Visual Studio doorbrengen, betekent sterkere PR-reviewondersteuning minder workflow-onderbrekingen en een soepeler pad van inspectie naar actie.

Dat is in mijn boek een waardevolle verbetering.

Originele publicatie: Pull requests reviewen zonder Visual Studio te verlaten

Agent-harnassen zijn belangrijk omdat prompts niet genoeg zijn

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

Een van de makkelijkste fouten in agent-ontwikkeling is denken dat de prompt het product is.

Dat is het niet.

De nieuwe agent harness- en claw-walkthrough van het Microsoft Agent Framework-team is waardevol omdat de focus blijft liggen op het deel dat echt bepaalt of een agent bruikbaar aanvoelt: de runtime-schil rond het model.

Dat omvat:

tools
planning
sessiestatus
geheugen
uitvoeringsmodi
een bruikbare console of interface om te itereren

Dat is waar agents ophouden slimme demo’s te zijn en beginnen aan te voelen als software.

Het harness-patroon is een praktisch patroon

Wat ik hier waardeer, is hoe toegankelijk het idee is.

Je begint met een chatclient.

Vervolgens verpak je die in een harness met instructies en tools.

Daarna voer je het uit via een shell die planning, todo’s, sessies en streaminginteractie ondersteunt.

Dat is een gezond patroon omdat het de verantwoordelijkheden duidelijk scheidt:

het model verzorgt de redenering
de harness verzorgt het runtimegedrag
de app bepaalt welke tools en ervaringen ertoe doen

Dit past heel goed bij hoe .NET-ontwikkelaars systemen bouwen

Het harness-idee sluit ook goed aan bij de .NET-mindset.

We doen het meestal beter wanneer runtimegedrag expliciet en samenstelbaar is. Middleware, pijplijnen, opties, providers en adapters voelen allemaal natuurlijk aan in deze wereld.

Daarom denk ik dat Agent Framework een goede kans heeft om aan te slaan bij .NET-ontwikkelaars. Het dwingt niet iedereen in één magische abstractie. Het geeft je gestructureerde runtime-onderdelen die je samen kunt bekabelen.

Mijn standpunt

Het nuttigste deel van deze post is de herinnering dat agents meer nodig hebben dan een goed model en een slimme instructiestring.

Ze hebben een runtime-schil nodig die ze structuur, geheugen, tooltoegang, planning en een werkbare ontwikkelaarslus geeft.

Dat is wat de harness je geeft.

En eerlijk gezegd, daarom is dit patroon de moeite van het opletten waard.

Oorspronkelijke post: Meet your agent harness and claw

Aspire in VS Code 13.4 verstrakt de ontwikkelaarslus op alle juiste manieren

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

De beste tooling-updates zijn degene die je na een paar dagen voelt, niet degene die alleen goed ogen in release notes.

Zo lees ik Aspire in VS Code 13.4.

Deze update draait helemaal om het verstrakken van de innerlijke lus: sneller projecten aanmaken, meertalige resources natuurlijker debuggen, gezondheid en commando’s direct in de editor tonen, en het dashboard dichtbij houden zonder het de enige plek te maken waar je kunt werken.

Dat is een heel goede richting.

De grote winst is minder contextwisselingen

Als je Aspire serieus gebruikt, beweeg je meestal over meerdere oppervlakken:

AppHost-code
terminal
dashboard
logs
debugsessies
service-endpoints

Wat 13.4 goed doet, is de wrijving tussen die oppervlakken verminderen.

De nieuwe VS Code-ervaring maakt meer van de app-status zichtbaar precies waar je al werkt:

resourcegezondheid in de editor
commando’s naast resourcedeclaraties
eenvoudiger dashboardtoegang
logtoegang vanuit de AppHost-context
een panel dat nuttig blijft, zelfs voordat volledige debugging begint

Dat klinkt klein totdat je het elke dag doet.

Debuggen van gemengde stacks is belangrijker dan mensen denken

Een van de sterkste onderdelen van deze update is het natuurlijkere verhaal voor het debuggen van C#, TypeScript, Python, Go, browserapps en Azure Functions in één Aspire-gedreven flow.

Dat weerspiegelt de echte vorm van moderne apps veel beter dan doen alsof alles in één enkele runtime leeft.

Voor .NET-ontwikkelaars is dat vooral waardevol, omdat velen van ons nu systemen bouwen die API-projecten, frontends, workers en AI-aangrenzende services in verschillende talen mengen.

Het feit dat Aspire dit meer uniform laat aanvoelen binnen VS Code is een zeer praktische verbetering.

TypeScript AppHost-ondersteuning die GA bereikt is ook betekenisvol

Ik zou de TypeScript AppHost-kant van deze release niet negeren.

Aspire wordt natuurlijker voor zowel C# als TypeScript en verbreedt wie in hetzelfde systeemmodel kan werken zonder vreemde tweederangs-workflows. Dat is belangrijk voor teams waar platformcode, frontendcode en service-orchestratie allemaal dicht bij elkaar leven.

Mijn standpunt

Aspire 13.4 in VS Code draait niet om één killer-feature. Het gaat om het gladstrijken van de ruwe randjes in de dagelijkse lus:

sneller starten
meer status zien waar je codeert
natuurlijker debuggen
alleen naar logs en het dashboard springen wanneer nodig

Dat is precies hoe goede tooling zou moeten evolueren.

Als je Aspire al gebruikt, lijkt deze update de moeite van het installeren waard. Als je je nog afvraagt of VS Code een serieus thuis is voor op Aspire gebaseerde ontwikkeling, wordt het antwoord steeds duidelijker.

Oorspronkelijke post: Aspire in VS Code: the 13.4 developer loop

De nieuwe Plan agent in Visual Studio lost een heel reëel AI-workflowprobleem op

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

Dit artikel is automatisch vertaald. Lees het origineel hier.

Een van de frustrerendste AI-coding workflows is wanneer de implementatie te snel begint.

De code kan zelfs technisch prima zijn, maar hij lost de verkeerde versie van het probleem op dat je in gedachten had.

Je wilde een refactor. Het begon met een rewrite. Je wilde een gerichte verbetering. Het raakte de helft van het project. Je wilde opties bespreken. Het ging meteen door naar file changes.

Daarom is de nieuwe Plan agent in Visual Studio zo’n nuttige toevoeging.

Dit lost een echt workflowprobleem op, niet alleen een cosmetisch probleem

De originele post beschrijft een heel bekende situatie: “De code is niet fout… hij is gewoon niet wat je bedoelde.”

Die zin is perfect.

Want de zwakke plek in veel AI-assisted development is niet of het model code kan maken. Het gaat erom of de workflow genoeg ruimte biedt om het beoogde shape van het werk af te stemmen voordat de implementatie begint.

Dat is vooral belangrijk voor:

grote features
onbekende codebases
niet-triviale refactorings
architectuurgevoelige veranderingen
werk dat eerst team review nodig heeft voordat edits beginnen

In zulke situaties is direct naar implementatie springen vaak de verkeerde zet.

Planning is geen overhead wanneer de taak echt is

Ik denk dat teams soms onderschatten hoeveel tijd ze verliezen door te vroeg met implementeren te beginnen.

Als de agent:

de verkeerde files aanraakt
de verkeerde aanpak kiest
een belangrijke constraint mist
een noodzakelijke edge case negeert

dan wordt de “snelle” start uiteindelijk een tragere workflow in totaal.

Daarom vind ik deze feature goed.

Hij maakt ruimte voor:

verhelderende vragen
het plan opstellen
het plan direct bewerken
het plan delen voordat codewijzigingen beginnen

Dat is geen bureaucratie. Het is vaak gewoon goede engineering.

De markdown plan file is een slimme keuze

Een detail dat ik vooral prettig vind, is dat elk plan wordt opgeslagen in .copilot/plans/plan-{title}.md.

Dat maakt de planningsstap tastbaar.

Het betekent dat het plan niet vastzit in een chat transcript. Het wordt iets dat je kunt:

reviewen
bewerken
mentaal versioneren
met teamleden bespreken
bewuster doorgeven aan implementatie

Daardoor voelt de feature veel serieuzer dan een tijdelijk voorwoord vóór codegeneratie.

Hier beginnen AI workflows het teamproces te respecteren

Ik denk dat dit een van de sterkere signalen is dat deze tools aan het rijpen zijn.

De beste AI developer workflows zijn niet degene die alle tussenstappen weghalen. Het zijn degene die de juiste tussenstappen verbeteren.

En planning is een van die stappen.

Als het plan sterk is, wordt implementatie makkelijker. Als het plan zwak is, wordt implementatie rumoerig.

Deze feature erkent dat direct.

Mijn mening

Dit is niet zomaar een AI extraatje.

Het is een workflowverbetering.

En voor echte features en echte refactorings is dit precies het soort verbetering dat veel onnodige churn, review noise en “dat bedoelde ik niet”-rework kan besparen.

Ik denk dat steeds meer agent-ervaringen uiteindelijk zoiets nodig zullen hebben.

Visual Studio is daar eerder aangekomen op een manier die nuttig aanvoelt.

Originele publicatie: Plan before you build: de Plan agent introduceren in Visual Studio

Je dev loop zit vol tribal knowledge, en Aspire geeft het juiste antwoord

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

Dit artikel is automatisch vertaald. Lees het origineel hier.

Dit is misschien wel een van de belangrijkste Aspire-posts om te begrijpen waarom het product ertoe doet.

Niet omdat het een grote nieuwe feature aankondigt.

Maar omdat het een probleem benoemt dat bijna elk engineeringteam heeft gevoeld, en niet elk team goed heeft beschreven:

de dev loop zit vol tribal knowledge.

Die uitspraak komt aan omdat hij waar is.

Het probleem is niet een gebrek aan tools

De kern van het originele artikel is uitstekend: teams missen vaak geen infrastructuur, scripts, dashboards of commands.

Wat ze missen is een samenhangend model dat alle verborgen operationele kennis rond de applicatie omzet in iets zichtbaars en herhaalbaars.

De echte architectuur van veel apps leeft in:

shell history
verspreide scripts
README-fragmenten
Slack-threads
die ene senior engineer die de volgorde van handelingen kent

Dat is geen duurzame dev loop voor mensen.

En zeker niet voor agents.

De quote die voor mij de hele post samenvat

Er staat één zin in het originele artikel die de bredere boodschap heel goed vangt:

“Applications already exist as systems. Aspire makes those systems explicit, because explicit systems scale better than tribal knowledge.”

Dat is de hele case in één regel.

En eerlijk gezegd is het een van de sterkste éénregelige verklaringen van Aspire die ik tot nu toe heb gezien.

Waarom dit nu meer telt dan een jaar geleden

Ik denk dat deze post vooral goed landt in het huidige moment omdat AI-assisted development de kosten van ambiguïteit verandert.

Mensen kunnen onvolledige systemen verrassend goed compenseren.

We onthouden:

welk script eerst moet draaien
welke environment variable stiekem nodig is
welk terminal meestal de nuttige logs laat zien
welke service twee keer opnieuw gestart moet worden om redenen die niemand heeft gedocumenteerd

Agents zijn veel slechter in dat soort verborgen operationele folklore.

Dus als we willen dat agents echt nuttig worden in echte repositories, moeten we het systeem explicieter maken, niet minder.

Daarom vind ik de Aspire-insteek belangrijk.

De echte waarde van Aspire is niet alleen orchestration

Een veelgemaakte fout is Aspire alleen zien als distributed app launcher of lokale orchestration-helper.

Dat is te klein gedacht.

De sterkere waardepropositie is dat Aspire de applicatie geeft:

een model
een shape
named resources
expliciete dependencies
health- en operations-surface
commands die zowel mensen als automation kunnen begrijpen

Dat verandert de dev loop meer dan mensen soms beseffen.

Want zodra de app geen stapel impliciete conventies meer is en een systeem met een echt model wordt, worden meerdere dingen tegelijk makkelijker:

onboarding
debugging
herhaalbare setup
CI-consistentie
AI-assisted workflows

Dat is veel leverage uit één designkeuze.

Ik vind vooral de “commands as first-class operations” invalshoek sterk

Een ander punt uit het originele artikel dat meer aandacht verdient, is de overgang van README-instructies naar resource-attached commands.

Dat is een deceptief grote verschuiving.

In plaats van te zeggen:

voer dit script uit, dan dat, en misschien nog iets anders als het eerste faalt

kun je operations direct in de context van de app modelleren.

Dat maakt ze voor mensen makkelijker te ontdekken.

En het betekent dat agents intentie niet uit proza hoeven te raden.

Dat is het soort ding dat een applicatie verandert van “operable als je hem al kent” naar “operable by design”.

Wat ik hieruit zou halen als team lead

Als ik de dev loop van mijn eigen team door deze lens zou bekijken, zou ik een paar directe vragen stellen:

hoe afhankelijk is onze setup van geheugen?
hoeveel kritieke dev-acties bestaan alleen in docs of chat-threads?
hoe vaak lopen nieuwe contributors vast op onzichtbaar systeemgedrag?
zou een automation tool of coding agent onze app-topologie uit de repo zelf kunnen begrijpen?

Als het antwoord op die laatste vraag “bij lange na niet” is, dan moet deze post een nuttige snaar raken.

Mijn mening

Dit is een heel sterk kader voor de echte waarde van Aspire.

Niet alleen orchestration.

Het is het app-model expliciet genoeg maken zodat het systeem makkelijker te bedienen, te begrijpen en te automatiseren is.

Dat is belangrijk voor mensen. Het is belangrijk voor teams. En het is nog belangrijker nu zoveel moderne development richting agent-assisted workflows beweegt.

Dit is precies het soort artikel dat helpt uitleggen waarom Aspire steeds relevanter aanvoelt dan alleen het .NET-marketinglabel.

Originele post: Je dev loop zit vol tribal knowledge— title: “Je dev-loop zit vol impliciete kennis, en Aspire heeft het juiste antwoord” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Een nieuwe Aspire-post maakt een sterk punt: veel teams missen geen tooling, ze missen een consistent applicatiemodel dat verborgen operationele kennis omzet in iets dat mensen, scripts en agents echt kunnen gebruiken.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

Dit artikel is automatisch vertaald. Lees het origineel hier.

Dit is misschien wel een van de belangrijkste Aspire-posts om te begrijpen waarom het product ertoe doet.

Niet omdat het een enorme nieuwe functie aankondigt.

Maar omdat het een probleem benoemt dat bijna elk engineeringteam heeft gevoeld en niet elk team goed heeft beschreven:

de dev-loop zit vol impliciete kennis.

Die zin blijft hangen omdat hij waar is.

Het probleem is niet een gebrek aan tools

De kern van het originele artikel is uitstekend: teams missen vaak geen infrastructuur, scripts, dashboards of commands.

Wat ze missen, is een coherent model dat alle verborgen operationele kennis rond de applicatie omzet in iets zichtbaars en herhaalbaars.

De echte architectuur van veel apps leeft in:

shell history
verspreide scripts
README-fragmenten
Slack-threads
die ene senior engineer die de volgorde van handelingen kent

Dat is geen duurzame dev-loop voor mensen.

En zeker ook niet voor agents.

Het citaat dat volgens mij de hele post samenvat

Er staat één zin in het bronartikel die de bredere boodschap heel goed vangt:

“Applicaties bestaan al als systemen. Aspire maakt die systemen expliciet, omdat expliciete systemen beter schalen dan impliciete kennis.”

Dat is de hele case in één regel.

En eerlijk gezegd is het een van de sterkste uitleggen in één zin van Aspire die ik tot nu toe heb gezien.

Waarom dit nu belangrijker is dan een jaar geleden

Ik denk dat deze post vooral nu goed landt, omdat AI-assisted development de kosten van ambiguïteit verandert.

Mensen kunnen verrassend goed omgaan met onvolledige systemen.

We onthouden:

welk script eerst moet draaien
welke environment variable stiekem nodig is
welke terminal meestal de nuttige logs laat zien
welke service twee keer opnieuw gestart moet worden om redenen die niemand heeft gedocumenteerd

Agents zijn veel slechter in dit soort verborgen operationele folklore.

Dus als we willen dat agents echt nuttig worden in echte repositories, moeten we het systeem explicieter maken, niet minder.

Daarom vind ik deze Aspire-framing belangrijk.

De echte waarde van Aspire is niet alleen orchestration

Een veelgemaakte fout met Aspire is dat het alleen wordt gezien als een distributed app launcher of een lokale orchestration-helper.

Dat is te klein gedacht.

De sterkere value proposition is dat Aspire de applicatie geeft:

een model
een vorm
benoemde resources
expliciete afhankelijkheden
health- en operations-oppervlakken
commands die zowel mensen als automation kunnen begrijpen

Dat verandert de dev-loop meer dan mensen soms doorhebben.

Want zodra de app geen stapel impliciete conventies meer is en een systeem met een echt model wordt, worden meerdere dingen in één keer makkelijker:

onboarding
debugging
herhaalbare setup
CI-consistentie
AI-assisted workflows

Dat is veel hefboomwerking uit één ontwerpkeuze.

Ik vind vooral de invalshoek “commands als first-class operations” sterk

Een ander punt uit de oorspronkelijke post dat volgens mij meer aandacht verdient, is de stap van README-instructies naar aan resources gekoppelde commands.

Dat is een misleidend grote verschuiving.

In plaats van te zeggen:

draai dit script, daarna dat, en misschien dit andere als het eerste faalt

kun je operaties direct in de applicatiecontext modelleren.

Dat betekent dat mensen ze makkelijker kunnen ontdekken.

En het betekent dat agents intentie niet uit proza hoeven te raden.

Dat is precies het soort ding dat een applicatie verandert van “operable als je het al kent” naar “operable by design”.

Wat ik hieruit zou meenemen als team lead

Als ik mijn eigen dev-loop door deze lens zou bekijken, zou ik een paar directe vragen stellen:

hoeveel van onze setup hangt af van geheugen?
hoeveel kritieke dev-acties bestaan alleen in docs of chat-threads?
hoe vaak lopen nieuwe contributors vast op onzichtbaar systeemgedrag?
zou een automation-tool of coding agent onze app-topologie uit de repo zelf kunnen begrijpen?

Als het antwoord op die laatste vraag “zeker niet” is, dan moet deze post op een nuttige plek raken.

Mijn mening

Dit is een zeer sterke framing van Aspire’s echte waarde.

Het gaat niet alleen om orchestration.

Het gaat erom het applicatiemodel expliciet genoeg te maken zodat het systeem makkelijker te bedienen, te begrijpen en te automatiseren is.

Dat is belangrijk voor mensen. Het is belangrijk voor teams. En het is nog belangrijker nu zoveel moderne ontwikkeling richting agent-assisted workflows beweegt.

Dit is precies het soort artikel dat helpt uitleggen waarom Aspire steeds relevanter aanvoelt dan alleen het .NET-marketinglabel.

Originele publicatie: Je dev-loop zit vol impliciete kennis

Aspire's hermetische end-to-end tests zijn een patroon dat meer teams zouden moeten overnemen

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

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Flaky end-to-end-tests zijn op een manier duur die niet altijd op een dashboard zichtbaar is.

Ze falen niet alleen. Ze leren het team langzaam om de feedbackloop niet meer te vertrouwen.

Daarom sprong dit Azure Chaos Studio + Aspire-artikel er meteen voor mij uit. Het is geen flashy productaankondiging. Het is een nuchter engineeringverhaal over hoe je end-to-end-tests kunt laten stoppen met voelen alsof je met geluk onderhandelt.

En eerlijk gezegd? Ik denk dat meer teams dit patroon zouden moeten overnemen.

Het kernidee is simpel, maar de winst is enorm

De sleutel is om elke test zijn eigen hermetische, tijdelijke omgeving te geven, met echte services, echte afhankelijkheden en een expliciete, health-gedreven start.

In één zin klinkt dat vanzelfsprekend. In echte systemen is het veel moeilijker, zeker zodra cloudafhankelijkheden, gedeelde omgevingen en gedistribueerde services meespelen.

Het oorspronkelijke artikel beschrijft het probleem heel duidelijk: gedeelde testomgevingen brengen “cross-talk, flaky gedrag en groepschatberichten van het type ‘wie heeft staging kapotgemaakt?’” met zich mee als operationele kosten.

Die zin is grappig omdat hij pijnlijk waar is.

Te veel teams accepteren die ruil als normaal. Ik vind niet dat ze dat zouden moeten doen.

Waarom dit patroon verder gaat dan testen

Wat ik hier het mooist aan vind, is dat het artikel niet alleen zegt: “we hebben onze tests betrouwbaarder gemaakt”.

Het zegt in feite iets groters:

als je gedistribueerde systeem moeilijk te reproduceren, moeilijk te isoleren en moeilijk te verifiëren is, vertraagt je hele engineeringloop.

Dat raakt meer dan alleen CI.

Het beïnvloedt:

hoe zeker ontwikkelaars refactoren
hoe snel regressies worden gediagnosticeerd
hoe veilig grotere architectuurwijzigingen kunnen worden geprobeerd
hoeveel vertrouwen het team heeft in geautomatiseerde validatie

En in 2026 beïnvloedt het ook hoe nuttig AI-ondersteunde ontwikkeling kan worden.

Het belangrijkste citaat in de post

Er is één zin in het artikel die ik echt wil herhalen:

“Agents hoeven niet perfect te zijn. Ze moeten verifieerbaar zijn.”

Dat is een uitstekende framing.

Mensen vragen zich vaak af of AI-coding agents betrouwbaar genoeg zijn om te helpen bij niet-triviaal werk. Ik denk dat de betere vraag is of onze systemen testbaar genoeg zijn om dat werk correct te beoordelen.

Als een agent een betekenisvolle refactor voorstelt en je enige veiligheidsignaal een stapel fragiele, half-willekeurige end-to-end checks op een gedeelde omgeving is, dan ligt het probleem niet alleen bij de agent.

Het probleem zit in je validatiemodel.

Dit Aspire-patroon verbetert dat drastisch.

Wat deze implementatie bijzonder goed maakt

Verschillende onderdelen van het oorspronkelijke verhaal maken dit veel meer dan een vaag “we hebben onze tests verbeterd”-bericht.

1. Echt servicegrafiek, geen neppe mock-theater

De tests zijn niet gebouwd op een stapel losgekoppelde mocks die doen alsof ze end-to-end validatie zijn.

Ze draaien de echte binaries, koppelen emulators waar dat kan en gebruiken hetzelfde application model als bij lokale ontwikkeling.

Dat is belangrijk.

Want zodra end-to-end-tests mock-tegen-mock-theater worden, zeggen ze je niets meer wat betrouwbaar is over de echte compositie.

2. Health-gedreven startup in plaats van magische sleeps

Dit deel is groter dan het lijkt.

Het artikel maakt expliciet duidelijk dat de tests wachten op echte health met WaitForResourceHealthyAsync, in plaats van op willekeurige timing-raadgissingen te vertrouwen.

Dat is een enorm verschil.

Een test suite die zegt: “slaap 30 seconden en hoop op het beste” documenteert in feite onzekerheid. Een suite die op echte readiness wacht, documenteert de intentie van het systeem.

3. Hetzelfde model stuurt lokale ontwikkeling en tests aan

Dat vind ik sterk, omdat het goed aansluit op de sterkste Aspire-verhalen in het algemeen.

Hetzelfde application model stuurt aan:

lokale ontwikkeling
service wiring
geëmuleerde afhankelijkheden
health checks
hermetische testorchestratie

Dat vermindert drift, en drift is een van de stilste killers van vertrouwen.

Dit soort investering in devex wordt onderschat

Een van de redenen waarom ik deze post langer wilde maken dan een snelle reactie, is dat ik denk dat dit soort engineeringverbeteringen vaak worden onderschat.

Ze zijn niet flashy.

Ze demoen niet zoals een nieuwe AI-functie.

En ze leveren ook niet altijd één slide op waar executives enthousiast van worden.

Maar na verloop van tijd creëren ze iets veel waardevollers: een team dat sneller kan bewegen zonder zichzelf voor de gek te houden over kwaliteit.

Dat is een groot ding.

Het artikel zegt dat ze nu ongeveer 90 hermetische tests draaien, inclusief scenario’s zoals zone-uitval, DNS-fouten en geo-replicatiefouten. Dat is niet alleen betere test-hygiëne. Dat is een veel sterker vertrouwensmodel voor een gedistribueerd platform.

Wat ik hieruit zou halen als ik een gedistribueerd .NET-systeem zou runnen

Als je vandaag met gedistribueerde services, Aspire en CI/CD-pipelines werkt, zou ik hier direct dit uithalen:

stop met het normaliseren van flakiness in gedeelde omgevingen
ga waar mogelijk over op health-based startup gates
behandel AppHost als echte orchestration code van productieniveau
bouw end-to-end checks die de samenstelling van services valideren, niet alleen de correctheid van losse services
als je AI-ondersteunde ontwikkeling omarmt, investeer dan eerst in checkability voordat je de automatiseringsbreedte oprekt

Dat laatste punt is het belangrijkste om door meer teams gehoord te worden.

Mijn take

Dit is een van de sterkste Aspire-posts in deze batch, omdat het een heel praktisch probleem oplost.

Het probeert je niet te imponeren met abstractie. Het laat zien hoe je end-to-end-tests deterministischer, nuttiger en betrouwbaarder maakt in een echt gedistribueerd systeem.

En zodra je de link met agent-ondersteunde ontwikkeling ziet, wordt het patroon alleen maar overtuigender.

Als je end-to-end testverhaal nog steeds afhankelijk is van gedeelde omgevingen, verborgen setup-kennis en een beetje gebed, is dit absoluut het bestuderen waard.

Origineel bericht: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests