Devops | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 findet vom 11. bis 15. Mai 2026 im Barbican Centre in London statt. Die 3-tägige Kernkonferenz läuft von Dienstag bis Donnerstag, mit optionalen Ganztags-Workshops am Montag und Freitag.

Mit 78 Sessions und 14 Workshops ist dies eine der umfangreichsten Entwicklerkonferenzen in Europa.

Themen

Architektonisches Denken
Funktionaler Code in C# 13
Serverless-Design
Semantische KI
Azure Kubernetes Services
Lean DevOps Strategien
The Model Context Protocol (MCP)
Agentische KI in .NET
Refactoring des Monolithen
Schneller programmieren mit LLMs
Kryptographie in einer Post-Quanten-Welt
Local-First-Entwicklung

Speaker

Weltklasse-Lineup mit Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm und Raju Gandhi.

Tickets und Infos

98 % der SDD 2025-Teilnehmer bewerteten das Gesamterlebnis als gut, sehr gut oder exzellent.

Azure Developer CLI (azd) April 2026 Updates

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Azure Developer CLI (azd) veröffentlichte fünf Releases im April 2026 (1.23.14 bis 1.24.2). Das große Thema: Hooks, die jetzt in Python, JavaScript, TypeScript und .NET ausgeführt werden – nicht mehr nur in Bash und PowerShell.

Mehrsprachige Hooks in azure.yaml

Hooks können nun neben Shell-Skripten auf .py-, .js-, .ts- oder .cs-Dateien verweisen. Jede Sprache erhält eine automatische Abhängigkeitsauflösung:

Python — erkennt requirements.txt oder pyproject.toml, erstellt ein Virtualenv und installiert Abhängigkeiten vor der Ausführung. Den Namen der Umgebung konfiguriert man mit virtualEnvName.
JavaScript / TypeScript — erkennt package.json und führt automatisch npm install aus. TypeScript wird über npx tsx ausgeführt, ohne Compile-Schritt. Den Paketmanager wählt man über den Konfigurationsblock packageManager.
.NET — führt .cs-Dateien mit dotnet run aus. Single-File-Skripte werden auf .NET 10+ unterstützt. Das Ziel-Framework wird über den Block configuration/framework konfiguriert.

Teams, die bereits in einer dieser Sprachen arbeiten, müssen keinen separaten Bash- oder PowerShell-Hook mehr pflegen, nur um Lifecycle-Events des Provisionierens zu verbinden.

azd update geht in die öffentliche Vorschau

azd update ist jetzt auf allen Plattformen in der öffentlichen Vorschau. Ein einzelner Befehl übernimmt das Update, unabhängig davon, wie azd ursprünglich installiert wurde – kein manuelles Nachverfolgen von Homebrew-, WinGet- oder MSI-Pfaden mehr.

Nicht-interaktiver Modus via AZD_NON_INTERACTIVE

Das Setzen von AZD_NON_INTERACTIVE=true (oder --non-interactive / --no-prompt) erzeugt nun konsistente, deterministische Fehler in CI/CD-Pipelines, wenn eine erforderliche Eingabe nicht automatisch aufgelöst werden kann. Zuvor war das Verhalten befehlsübergreifend inkonsistent.

KI-Modell-Quota-Preflight-Check

azd provision validiert die Azure Cognitive Services Quota, bevor KI-Modellressourcen bereitgestellt werden. Deployments, die aufgrund von Quota-Grenzen scheitern würden, zeigen den Fehler jetzt früh im Prozess an – nicht erst in der Mitte des Provisionierens.

„Diesen Fehler beheben" in der Copilot-Fehlerbehebung

Die azd-Copilot-Integration zur Fehlerbehebung gewinnt die Fähigkeit, einen vorgeschlagenen Fix direkt anzuwenden – nicht nur zu beschreiben. Wenn der Agent ein behebbares Problem erkennt, kann er die Änderung direkt vornehmen.

Benutzerdefinierte Provisionierungsanbieter und Key Vault Secret Resolver

Erweiterungsautoren können nun alternative Infrastruktur-Backends mit WithProvisioningProvider() registrieren. Außerdem löst azd @Microsoft.KeyVault(...)-Referenzen automatisch auf, bevor die Konfiguration an Erweiterungen übergeben wird – manuelle Secret-Auflösung in benutzerdefinierten Anbietern entfällt.

Ausschlüsse für Templates und Watch-Modus

Zwei neue Ignore-Dateien bieten feinere Kontrolle über die Dateiverarbeitung:

.azdignore — schließt beitragerspezifische Dateien (Dokumentation, CI-Konfigurationen) aus Template-Kopien aus, damit Endnutzer ein sauberes Projektgerüst erhalten.
.azdxignore — schließt Verzeichnisse aus, die während azd x watch Rebuilds auslösen, und reduziert so Lärm bei der iterativen Entwicklung.

Reserved-Name-Preflight und docker.network-Option

azd warnt nun, wenn vorhergesagte Ressourcennamen reservierte Azure-Wörter (MICROSOFT, WINDOWS oder das Präfix LOGIN) enthalten – bevor die Provisionierung beginnt. Eine neue docker.network-Option übergibt --network an docker build, was in Unternehmens-Proxy-Umgebungen nützlich ist, die ein bestimmtes Docker-Netzwerk erfordern.

Sicherheitsfixes

Das Windows-MSI-Paket enthält jetzt eine Code-Signing-Verifizierung. Ein weiterer Fix schließt ein Environment-Variable-Leak, das Werte über Erweiterungsbefehlsgrenzen hinweg hätte offenlegen können.

Ein intensiver Monat – der mehrsprachige Hook-Support beseitigt insbesondere einen echten Reibungspunkt für Teams, die nicht hauptsächlich in Bash arbeiten. Die vollständigen Release Notes enthalten das komplette Changelog aller fünf Releases.

Azure DevOps Server April 2026 Patch — Fix für PR-Abschluss und Sicherheitsupdates

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kurzer Hinweis für Teams, die selbst gehosteten Azure DevOps Server betreiben: Microsoft hat Patch 3 für April 2026 mit drei gezielten Fixes veröffentlicht.

Was behoben wurde

Fehlgeschlagene Pull-Request-Abschlüsse — eine Null-Referenz-Ausnahme beim automatischen Abschluss von Work Items konnte dazu führen, dass PR-Merges fehlschlugen. Wenn du auf zufällige Fehler beim PR-Abschluss gestoßen bist, ist das wahrscheinlich die Ursache
Validierung der Abmelde-Weiterleitung — verbesserte Validierung beim Abmelden, um potenziell bösartige Weiterleitungen zu verhindern. Das ist ein Sicherheitsfix, den man zeitnah anwenden sollte
GitHub Enterprise Server PAT-Verbindungen — das Erstellen von Personal-Access-Token-Verbindungen zu GitHub Enterprise Server war defekt, jetzt funktioniert es wieder

So aktualisierst du

Lade Patch 3 herunter und starte den Installer. Um zu überprüfen, ob der Patch angewendet wurde:

<patch-installer>.exe CheckInstall

Wenn du Azure DevOps Server on-premises betreibst, empfiehlt Microsoft dringend, immer auf dem neuesten Patch zu bleiben — sowohl für Sicherheit als auch Zuverlässigkeit. Schau dir die Release Notes für alle Details an.

Agentisches Platform Engineering Wird Realität — Git-APE Zeigt Wie

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Platform Engineering war einer dieser Begriffe, die auf Konferenzen toll klingen, aber normalerweise bedeuten: „Wir haben ein internes Portal und einen Terraform-Wrapper gebaut." Das eigentliche Versprechen — Self-Service-Infrastruktur, die wirklich sicher, kontrolliert und schnell ist — war immer noch ein paar Schritte entfernt.

Das Azure-Team hat gerade Teil 2 ihrer Serie über agentisches Platform Engineering veröffentlicht, und in diesem Teil geht es um die praktische Umsetzung. Sie nennen es Git-APE (ja, das Akronym ist beabsichtigt), und es ist ein Open-Source-Projekt, das GitHub Copilot Agents plus Azure MCP Server nutzt, um natürlichsprachliche Anfragen in validierte, deployed Infrastruktur umzuwandeln.

Was Git-APE tatsächlich macht

Die Kernidee: Anstatt dass Entwickler Terraform-Module lernen, durch Portal-UIs navigieren oder Tickets beim Platform-Team einreichen, sprechen sie mit einem Copilot-Agenten. Der Agent interpretiert die Absicht, generiert Infrastructure-as-Code, validiert sie gegen Richtlinien und deployt — alles innerhalb von VS Code.

Hier ist das Setup:

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

Öffne den Workspace in VS Code, und die Agent-Konfigurationsdateien werden automatisch von GitHub Copilot erkannt. Du interagierst direkt mit dem Agenten:

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

Der Agent nutzt Azure MCP Server unter der Haube, um mit Azure-Diensten zu interagieren. Die MCP-Konfiguration in den VS Code-Einstellungen aktiviert spezifische Fähigkeiten:

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

Warum das wichtig ist

Für diejenigen von uns, die auf Azure bauen, verschiebt dies die Platform-Engineering-Diskussion von „wie bauen wir ein Portal" zu „wie beschreiben wir unsere Leitplanken als APIs." Wenn die Schnittstelle deiner Plattform ein KI-Agent ist, wird die Qualität deiner Einschränkungen und Richtlinien zum Produkt.

Der Blog von Teil 1 legte die Theorie dar: gut beschriebene APIs, Kontrollschemata und explizite Leitplanken machen Plattformen agent-ready. Teil 2 beweist, dass es funktioniert, indem tatsächliche Werkzeuge ausgeliefert werden. Der Agent generiert nicht blind Ressourcen — er validiert gegen Best Practices, respektiert Namenskonventionen und wendet die Richtlinien deiner Organisation an.

Das Aufräumen ist genauso einfach:

@git-ape destroy my-resource-group

Meine Einschätzung

Ich bin ehrlich — hier geht es mehr um das Muster als um das spezifische Tool. Git-APE selbst ist eine Demo/Referenzarchitektur. Aber die zugrundeliegende Idee — Agenten als Interface zu deiner Plattform, MCP als Protokoll, GitHub Copilot als Host — ist die Richtung, in die sich die Enterprise-Developer-Experience bewegt.

Wenn du ein Platform-Team bist, das darüber nachdenkt, wie man interne Werkzeuge agent-freundlich macht, gibt es keinen besseren Startpunkt. Und wenn du ein .NET-Entwickler bist, der sich fragt, wie das mit deiner Welt zusammenhängt: Der Azure MCP Server und GitHub Copilot Agents funktionieren mit jedem Azure-Workload. Deine ASP.NET Core API, dein .NET Aspire Stack, deine containerisierten Microservices — all das kann Ziel eines agentischen Deployment-Flows sein.

Zusammenfassung

Git-APE ist ein früher, aber konkreter Blick auf agentisches Platform Engineering in der Praxis. Klone das Repo, probiere die Demo aus und fange an darüber nachzudenken, wie die APIs und Richtlinien deiner Plattform aussehen müssten, damit ein Agent sie sicher nutzen kann.

Lies den vollständigen Post für den Walkthrough und Video-Demos.

Azure DevOps behebt endlich den Markdown-Editor, über den sich alle beschwert haben

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du Azure Boards benutzt, hast du das wahrscheinlich erlebt: Du liest eine Work-Item-Beschreibung durch, vielleicht überprüfst du Akzeptanzkriterien, und du machst versehentlich einen Doppelklick. Boom — du bist im Bearbeitungsmodus. Du wolltest nichts bearbeiten. Du hast nur gelesen.

Dan Hellem hat den Fix angekündigt, und es ist eine dieser Änderungen, die klein klingen, aber echte Reibung aus deinem täglichen Workflow entfernen.

Was sich geändert hat

Der Markdown-Editor für Work-Item-Textfelder öffnet jetzt standardmäßig im Vorschaumodus. Du kannst den Inhalt lesen und damit interagieren — Links folgen, Formatierung überprüfen — ohne dir Sorgen zu machen, versehentlich in den Bearbeitungsmodus zu gelangen.

Wenn du wirklich bearbeiten willst, klickst du auf das Bearbeiten-Symbol oben am Feld. Wenn du fertig bist, verlässt du den Modus explizit. Einfach, bewusst, vorhersagbar.

Warum das wichtiger ist als es klingt

Der Community-Feedback-Thread dazu war lang. Das Doppelklick-zum-Bearbeiten-Verhalten wurde im Juli 2025 mit dem Markdown-Editor eingeführt, und die Beschwerden begannen fast sofort.

Für Teams, die Sprint-Planung, Backlog-Pflege oder Code-Reviews mit Azure Boards machen, summiert sich diese Mikro-Reibung. Jeder versehentliche Bearbeitungsmodus-Eintritt ist ein Kontextwechsel.

Rollout-Status

Dies wird bereits an einen Teil der Kunden ausgerollt und über die nächsten zwei bis drei Wochen auf alle erweitert.

Zusammenfassung

Nicht jede Verbesserung muss ein Headliner sein. Manchmal ist das beste Update einfach etwas Nerviges zu entfernen. Das hier ist genau so eine — ein kleiner UX-Fix, der Azure Boards weniger feindselig für Leute macht, die einfach nur ihre Work Items in Ruhe lesen wollen.

Azure DevOps MCP Server landet in Microsoft Foundry: Was das für deine KI-Agenten bedeutet

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

MCP (Model Context Protocol) hat gerade seinen Moment. Wenn du das KI-Agenten-Ökosystem verfolgst, hast du wahrscheinlich bemerkt, dass MCP-Server überall auftauchen — sie geben Agenten die Fähigkeit, über ein standardisiertes Protokoll mit externen Tools und Diensten zu interagieren.

Jetzt ist der Azure DevOps MCP Server in Microsoft Foundry verfügbar, und das ist eine dieser Integrationen, die einen über die praktischen Möglichkeiten nachdenken lässt.

Was hier tatsächlich passiert

Microsoft hat den Azure DevOps MCP Server bereits als Public Preview veröffentlicht — das ist der MCP-Server selbst. Neu ist die Foundry-Integration. Du kannst den Azure DevOps MCP Server jetzt direkt aus dem Tool-Katalog zu deinen Foundry-Agenten hinzufügen.

Für diejenigen, die Foundry noch nicht kennen: Es ist Microsofts einheitliche Plattform zum Erstellen und Verwalten von KI-gestützten Anwendungen und Agenten im großen Maßstab. Modellzugriff, Orchestrierung, Evaluierung, Deployment — alles an einem Ort.

Die Einrichtung

Die Einrichtung ist überraschend unkompliziert:

Gehe in deinem Foundry-Agenten zu Add Tools > Catalog
Suche nach “Azure DevOps”
Wähle den Azure DevOps MCP Server (Preview) und klicke auf Create
Gib deinen Organisationsnamen ein und verbinde

Das war’s. Dein Agent hat jetzt Zugriff auf Azure DevOps-Tools.

Kontrollieren, worauf dein Agent zugreifen kann

Das ist der Teil, den ich schätze: Du bist nicht auf einen Alles-oder-Nichts-Ansatz festgelegt. Du kannst festlegen, welche Tools deinem Agenten zur Verfügung stehen. Wenn du also willst, dass er nur Work Items lesen, aber keine Pipelines anfassen darf, kannst du das konfigurieren. Prinzip der minimalen Berechtigung, angewandt auf deine KI-Agenten.

Das ist wichtig für Enterprise-Szenarien, in denen du nicht willst, dass ein Agent versehentlich eine Deployment-Pipeline auslöst, weil jemand ihn gebeten hat, “beim Release zu helfen.”

Warum das für .NET-Teams interessant ist

Denk darüber nach, was das in der Praxis ermöglicht:

Sprint-Planungsassistenten — Agenten, die Work Items abrufen, Velocity-Daten analysieren und Sprint-Kapazität vorschlagen können
Code-Review-Bots — Agenten, die deinen PR-Kontext verstehen, weil sie tatsächlich deine Repos und verknüpften Work Items lesen können
Incident Response — Agenten, die Work Items erstellen, kürzliche Deployments abfragen und Bugs mit kürzlichen Änderungen korrelieren können
Entwickler-Onboarding — “Woran sollte ich arbeiten?” bekommt eine echte Antwort, gestützt auf tatsächliche Projektdaten

Für .NET-Teams, die Azure DevOps bereits für ihre CI/CD-Pipelines und Projektverwaltung nutzen, ist ein KI-Agent, der direkt mit diesen Systemen interagieren kann, ein bedeutender Schritt in Richtung nützlicher Automatisierung.

Das größere MCP-Bild

Das ist Teil eines breiteren Trends: MCP-Server werden zum Standard, wie KI-Agenten mit der Außenwelt interagieren. Wir sehen sie für GitHub, Azure DevOps, Datenbanken, SaaS-APIs — und Foundry wird zum Hub, wo all diese Verbindungen zusammenkommen.

Wenn du Agenten im .NET-Ökosystem baust, lohnt es sich, MCP im Auge zu behalten. Das Protokoll ist standardisiert, das Tooling reift heran, und die Foundry-Integration macht es zugänglich, ohne Server-Verbindungen manuell einrichten zu müssen.

Zusammenfassung

Der Azure DevOps MCP Server in Foundry ist in der Preview, also rechne damit, dass er sich weiterentwickelt. Aber der Kern-Workflow ist solide: verbinden, Tool-Zugriff konfigurieren und deine Agenten mit deinen DevOps-Daten arbeiten lassen. Wenn du bereits im Foundry-Ökosystem bist, ist das nur ein paar Klicks entfernt. Probier es aus und schau, welche Workflows du bauen kannst.

Schau dir die vollständige Ankündigung für die Schritt-für-Schritt-Einrichtung und weitere Details an.