<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Ci-Cd | The .NET Blog</title><link>https://thedotnetblog.com/nl/tags/ci-cd/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>nl</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Sat, 18 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/nl/tags/ci-cd/index.xml" rel="self" type="application/rss+xml"/><item><title>MCP-builddiagnostiek in CI is de eerste AI-workflow die zichzelf echt snel terugbetaalt</title><link>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/</guid><description>Wanneer Binlog MCP-analyse direct draait in pull-requestworkflows, verminderen teams de tijd voor faaltriage en ontgrendelen ze ontwikkelaars sneller.</description><content:encoded>&lt;p&gt;Oorspronkelijke bron: &lt;a href="https://devblogs.microsoft.com/dotnet/mcp-build-diagnostics-workflows/"&gt;MCP Beyond the Chat Window: Build Diagnostics in CI&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Dit is een van de sterkste praktische MCP-verhalen tot nu toe omdat het de chatdemowereld verlaat en de pijplijnrealiteit betreedt.&lt;/p&gt;
&lt;p&gt;Het getoonde patroon is overtuigend: een mislukte PR-build triggert agentanalyse tegen binlog via MCP, waarna de workflow bruikbare root-cause-context terugplaatst op de pull request. Dat is precies waar ontwikkelaarstijd vandaag meestal wordt verspild.&lt;/p&gt;
&lt;p&gt;De meeste teams behandelen rode builds nog steeds met dure handmatige lussen:&lt;/p&gt;
&lt;p&gt;Binlog downloaden.&lt;/p&gt;
&lt;p&gt;Viewer openen.&lt;/p&gt;
&lt;p&gt;Falend target en taak traceren.&lt;/p&gt;
&lt;p&gt;Bevindingen vertalen voor reviewers.&lt;/p&gt;
&lt;p&gt;MCP-gebaseerde binlog-tooling comprimeert die lus en maakt analyse beschikbaar voor elke bijdrager, niet alleen de build-specialist die dienst heeft.&lt;/p&gt;
&lt;p&gt;De advisory-only-houding in de workflow is ook een slimme architecturale keuze. Behoud merge-gating met je bestaande vereiste builds, en gebruik agentdiagnostiek als versnelling in plaats van als autoriteit. Dat behoudt vertrouwen terwijl het toch productiviteitswinst oplevert.&lt;/p&gt;
&lt;p&gt;Het uitgebreide tooloppervlak is opmerkelijk. Target-redenering, evaluatie-eigenschappen, analyzer-kostenuitsplitsingen, critical-path-grafen, restore-analyse en inspectie van incrementeel gedrag zijn precies het soort gestructureerde diagnostiek dat taalmodellen goed aankunnen wanneer ze via precieze tools worden blootgesteld.&lt;/p&gt;
&lt;p&gt;Mijn eigenzinnige mening: hier wordt AI in engineering daadwerkelijk infrastructuur. Als een mogelijkheid betrouwbaar de gemiddelde tijd verkort om buildfouten uit te leggen zonder riskante autonomie toe te voegen, hoort het standaard thuis in CI.&lt;/p&gt;
&lt;p&gt;De evaluatiedata versterkt de argumentatie. Betere scores met aanzienlijk lagere wandkloktijd en tokengebruik vergeleken met baselines zonder tools tonen aan dat de productiviteitswinst niet anekdotisch is.&lt;/p&gt;
&lt;p&gt;Praktisch uitrolplan voor .NET-teams:&lt;/p&gt;
&lt;p&gt;Maak /bl-generatie standaard in CI voor relevante build- en testtaken.&lt;/p&gt;
&lt;p&gt;Introduceer MCP-diagnostische commentaren eerst in één niet-kritieke repository.&lt;/p&gt;
&lt;p&gt;Volg triagetijd-metrics en het percentage vals-positieve verklaringen.&lt;/p&gt;
&lt;p&gt;Breid alleen uit nadat commentaarkwaliteit en ontwikkelaarsacceptatie zijn bewezen.&lt;/p&gt;
&lt;p&gt;Eén waarschuwing: behandel toolmogelijkheden als geversioneerde contracten. Serveroppervlakken evolueren, en workflowbetrouwbaarheid hangt af van expliciete compatibiliteitscontroles. Capability-discoverytooling zou onderdeel moeten zijn van je pijplijnopzet.&lt;/p&gt;
&lt;p&gt;Als je organisatie op zoek is geweest naar een hoogvertrouwen-AI-adoptiepunt in softwarelevering, is dit het. Het is afgebakend, meetbaar en direct gekoppeld aan de ontwikkelaarscyclustijd.&lt;/p&gt;
&lt;p&gt;MCP is hier geen nieuwigheidslaag. Het is een transport voor gestructureerde operationele intelligentie, en buildpijplijnen zijn een ideale plek om het te benutten.&lt;/p&gt;</content:encoded></item><item><title>De beste azd-updates zijn degene die teamkwetsbaarheid wegnemen</title><link>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/</guid><description>De laatste azd-cyclus draait minder om glimmende commando's en meer om het verminderen van deploymentchaos in echte teams.</description><content:encoded>&lt;p&gt;Oorspronkelijke bron: &lt;a href="https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-may-june-2026/"&gt;Azure Developer CLI (azd) – May and June 2026&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Negen releases in twee maanden kan rommelig lijken, maar deze azd-batch heeft een duidelijke rode draad: de broze randjes wegnemen die teams pijn doen in CI en multi-service deployments.&lt;/p&gt;
&lt;p&gt;De belangrijkste feature is voor mij niet alleen azd tool. Het is de productbeslissing om vereisten te behandelen als eersteklas workflowstatus. In de praktijk zijn veel mislukte cloud-deployments geen architectuurfouten. Het zijn inconsistente lokale en CI-omgevingen. Wanneer de CLI vereiste tooling in-band kan ontdekken, installeren en verifiëren, verminderen teams een van de meest wrijvingsvolle faalbronnen.&lt;/p&gt;
&lt;p&gt;De tweede grote winst is azd exec. Dit is belangrijk omdat deploymentscripts vaak wegdrijven van de omgevingscontext, vooral bij het oplossen van secrets en het doorgeven van variabelen. Een cross-platform runner die de volledige azd-omgeving erft, verlaagt die drift en maakt scripts makkelijker te vertrouwen.&lt;/p&gt;
&lt;p&gt;Concurrency-fixes verdienen speciale aandacht. Cross-service-imagevervuiling in parallelle Container Apps-deployments is precies het soort defect dat het vertrouwen in automatisering vernietigt. Je kunt niet prediken over platform-engineering terwijl je pijplijn af en toe de verkeerde image naar de verkeerde service verzendt. Het feit dat deze releasegolf die race conditions aanpakte, is belangrijker dan de meeste nieuwe features.&lt;/p&gt;
&lt;p&gt;Mijn praktische aanbeveling voor platformteams:&lt;/p&gt;
&lt;p&gt;Neem azd tool check op als een verplichte preflight in CI.&lt;/p&gt;
&lt;p&gt;Bekijk eventuele aangepaste parsers of regex-checks gekoppeld aan de oude azd up-output, want het uniforme voortgangsmodel is een breaking gedragsverandering.&lt;/p&gt;
&lt;p&gt;Schakel subscription filtering nu in en test dit voor multi-tenant organisaties, voordat je volgende grote omgevingsuitrol.&lt;/p&gt;
&lt;p&gt;Voer een gecontroleerde parallel-deploy stresstest uit als je remote builds met Container Apps gebruikt.&lt;/p&gt;
&lt;p&gt;Ik waardeer ook de verschuiving naar bruikbare preflight-waarschuwingen en machine-leesbare deployment-identifiers. Dat is de brug van developer-vriendelijke UX naar operations-grade observability.&lt;/p&gt;
&lt;p&gt;Mijn eigenzinnige mening is dat azd volwassen wordt van template-launcher naar delivery-substraat. Dat is goed, maar het brengt een verantwoordelijkheid voor teams met zich mee: stop met azd-upgrades behandelen als optionele huishouding. Gezien het aantal beveiligings- en betrouwbaarheidsfixes in deze notities, is achterblijven niet langer neutraal. Het is actieve risicoacceptatie.&lt;/p&gt;
&lt;p&gt;Als je team azd gebruikt in productiepaden, is het juiste beleid simpel: pin versies bewust, test upgrades snel en beweeg mee. De snelheid van deze releasecyclus laat zien waar cloud-tooling naartoe gaat. Tools die zichzelf niet verharden onder parallellisme en schaal, worden verlaten.&lt;/p&gt;
&lt;p&gt;Deze releasetrein bewijst dat azd probeert er een te zijn die echte enterprise-druk overleeft.&lt;/p&gt;</content:encoded></item></channel></rss>