https://thedotnetblog.com/de/tags/ci-cd/Articles, tutorials and insights from the .NET community.Hugode@thedotnetblog (The .NET Blog)@thedotnetblogSat, 18 Jul 2026 00:00:00 +0000https://thedotnetblog.com/de/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/Sat, 18 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/mcp-binlog-ci-build-diagnostics/Wenn Binlog-MCP-Analyse direkt in Pull-Request-Workflows läuft, reduzieren Teams die Fehlertriage-Zeit und entsperren Entwickler schneller.<p>Originalquelle: <a href="https://devblogs.microsoft.com/dotnet/mcp-build-diagnostics-workflows/">MCP Beyond the Chat Window: Build Diagnostics in CI</a></p> <p>Dies ist eine der stärksten praktischen MCP-Geschichten, weil sie die Chat-Demo-Welt verlässt und in die Pipeline-Realität eintritt.</p> <p>Das gezeigte Muster ist überzeugend: Ein fehlgeschlagener PR-Build löst eine Agent-Analyse gegen binlog über MCP aus, dann postet der Workflow verwertbaren Root-Cause-Kontext zurück an den Pull-Request. Genau dort wird Entwicklerzeit heute normalerweise verschwendet.</p> <p>Die meisten Teams behandeln rote Builds immer noch mit teuren manuellen Schleifen:</p> <ul> <li>Binlog herunterladen.</li> <li>Viewer öffnen.</li> <li>Fehlgeschlagenes Ziel und Task verfolgen.</li> <li>Ergebnisse für Reviewer übersetzen.</li> </ul> <p>MCP-basiertes Binlog-Tooling komprimiert diese Schleife und macht die Analyse jedem Mitwirkenden zugänglich, nicht nur dem Build-Spezialisten.</p> <p>Die reine Beratungshaltung im Workflow ist auch eine kluge architektonische Wahl. Behalten Sie Merge-Gating mit Ihren bestehenden erforderlichen Builds bei und verwenden Sie Agent-Diagnostik als Beschleunigung statt Autorität. Dies bewahrt Vertrauen, während es dennoch Produktivitätsgewinne erfasst.</p> <p>Meine Meinung: <strong>hier wird KI im Engineering tatsächlich zur Infrastruktur</strong>. Wenn eine Fähigkeit zuverlässig die mittlere Zeit zur Erklärung von Build-Fehlern reduziert, ohne riskante Autonomie hinzuzufügen, gehört sie standardmäßig in CI.</p> <p>Praktischer Einführungsplan für .NET-Teams:</p> <ul> <li><strong>Machen Sie /bl-Erzeugung zum Standard</strong> in CI für relevante Build- und Test-Jobs.</li> <li><strong>Führen Sie MCP-Diagnosekommentare</strong> zuerst in einem nicht-kritischen Repository ein.</li> <li><strong>Verfolgen Sie Triage-Zeit-Metriken</strong> und die False-Positive-Erklärungsrate.</li> <li><strong>Erweitern Sie erst nach Nachweis</strong> von Kommentarqualität und Entwicklerakzeptanz.</li> </ul>https://thedotnetblog.com/de/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/Tue, 14 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/azd-may-june-2026-operational-upgrades/Der neueste azd-Zyklus dreht sich weniger um glänzende Befehle und mehr um die Reduzierung von Deployment-Chaos in echten Teams.<p>Originalquelle: <a href="https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-may-june-2026/">Azure Developer CLI (azd) – May and June 2026</a></p> <p>Neun Releases in zwei Monaten können laut wirken, aber dieser azd-Batch hat einen klaren roten Faden: <strong>Entferne die brüchigen Kanten</strong>, die Teams in CI und Multi-Service-Deployments verbrennen.</p> <p>Das Hauptfeature für mich ist nicht nur <code>azd tool</code>. Es ist die Produktentscheidung, <strong>Voraussetzungen als First-Class-Workflow-Status zu behandeln</strong>. In der Praxis sind viele fehlgeschlagene Cloud-Deployments keine Architekturfehler. Sie sind inkonsistente lokale und CI-Umgebungen. Wenn die CLI erforderliche Tooling im Band entdecken, installieren und verifizieren kann, reduzieren Teams eine der reibungsintensivsten Fehlerquellen.</p> <p>Der zweite große Gewinn ist <code>azd exec</code>. Das ist wichtig, weil Deployment-Skripte oft vom Umgebungskontext abdriften, besonders bei Secret-Auflösung und Variablenpropagation. Ein plattformübergreifender Runner, der die gesamte azd-Umgebung erbt, senkt diese Drift und macht Skripte vertrauenswürdiger.</p> <p><strong>Concurrency-Fixes</strong> verdienen besondere Aufmerksamkeit. Image-Kontamination zwischen Diensten in parallelen Container Apps-Deployments ist genau die Art von Fehler, die Vertrauen in Automatisierung zerstört. Sie können kein Plattform-Engineering predigen, während Ihre Pipeline gelegentlich das falsche Image an den falschen Dienst ausliefert. Die Tatsache, dass diese Release-Welle diese Race Conditions angegangen ist, ist wichtiger als die meisten neuen Funktionen.</p> <h3 id="meine-praktische-empfehlung-für-plattformteams">Meine praktische Empfehlung für Plattformteams</h3> <ul> <li><strong>Führen Sie <code>azd tool check</code></strong> als erforderlichen Preflight in CI ein.</li> <li><strong>Überprüfen Sie alle benutzerdefinierten Parser oder Regex-Checks</strong>, die an alte <code>azd up</code>-Ausgaben gebunden sind, da das einheitliche Fortschrittsmodell eine breaking-change ist.</li> <li><strong>Aktivieren und testen Sie Abonnementfilterung</strong> für Multi-Tenant-Organisationen jetzt, vor Ihrem nächsten großen Environment-Rollout.</li> <li><strong>Führen Sie einen kontrollierten Parallel-Deploy-Stresstest durch</strong>, wenn Sie Remote-Builds mit Container Apps verwenden.</li> </ul> <p>Mir gefällt auch die Verschiebung hin zu <strong>handlungsorientierten Preflight-Warnungen</strong> und <strong>maschinenlesbaren Deployment-Identifikatoren</strong>. Das ist die Brücke von entwicklerfreundlicher UX zu operations-tauglicher Beobachtbarkeit.</p> <p>Meine Meinung: azd wächst vom Template-Launcher zum Delivery-Substrat. Das ist gut, bringt aber Verantwortung für Teams: Hören Sie auf, azd-Upgrades als optionale Hausarbeit zu betrachten. Angesichts der Anzahl von Sicherheits- und Zuverlässigkeitsfixes in diesen Notes ist Zurückbleiben nicht mehr neutral. Es ist aktive Risikoakzeptanz.</p> <p>Originalquelle: <a href="https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-may-june-2026/">Azure Developer CLI (azd) – May and June 2026</a></p>