Letztes Jahr. Mittelständischer Maschinenbauer, 80 Mitarbeiter, vier .NET-Entwickler im Haus. Der Senior-Dev beschwert sich seit Monaten, dass die CI-Pipeline langsam ist. Ich schaue rein: lokale Builds dauern vier Minuten, die Pipeline sechs. Alle arbeiten auf Firmen-Notebooks mit Standard-Windows-Image, NTFS, Defender auf Vollgas, NuGet-Cache irgendwo auf C:. Klassisch.
Ich frage, ob jemand schon mal von Dev Drive gehört hat. Zwei von vier nicken vage. Einer sagt, er habe mal was gelesen, aber "das brauche man doch wohl eher für große Teams". Das ist genau der Denkfehler, den ich immer wieder antreffe — und den ich hier gerade rücken will.
Was Maarten Balliauw gemacht hat
Maarten Balliauw — bekannt in der .NET-Community, arbeitet bei JetBrains — hat sich Dev Drive systematisch vorgeknöpft. Dev Drive ist ein Windows-11-Feature: ein Laufwerk auf Basis des Resilient File System (ReFS) statt NTFS, kombiniert mit einem asynchronen Defender-Scanmodus, der den Real-Time-Overhead deutlich reduziert. Microsoft verspricht bis zu 30 % schnellere Build-Zeiten.
Balliauw hat das Ganze praktisch durchgespielt: physische Partition vs. virtuelle Festplatte, NuGet- und npm-Caches umgezogen, Maven und Gradle konfiguriert, sogar seine IDE von Dev Drive gestartet. Sein Fazit ist differenziert — die Gewinne sind real, aber nicht dramatisch, und es gibt Kompatibilitätsprobleme (OneDrive z. B. läuft nicht auf ReFS). Wer den vollständigen technischen Bericht mit Messungen und Konfigurationsdetails will, ist bei ihm genau richtig.
Wie das im KMU wirklich landet
Jetzt kommt der Teil, den Maarten als JetBrains-Mitarbeiter mit eigenem Hochleistungs-Laptop naturgemäß nicht schreibt — weil er ihn nicht schreiben muss.
Das Notebook-Problem
In KMU-Entwicklungsabteilungen gibt es selten einen Standard für Entwickler-Hardware. Was ich typischerweise vorfinde: ein Mix aus drei bis vier Notebook-Generationen, zentral verwaltet via Intune oder GPO, und ein IT-Verantwortlicher, der für 80 User zuständig ist — davon vier Entwickler. Der hat keine Zeit, für eine Handvoll Leute ein eigenes Windows-Image zu pflegen.
Dev Drive erfordert Windows 11 in einer aktuellen Version und mindestens 50 GB freien Speicher für das neue Volume. Klingt nach wenig. In der Praxis scheitert es aber oft daran, dass die C:-Partition auf einem drei Jahre alten Notebook schon auf Kante genäht ist, Schreibrechte für Datenträgerverwaltung per Policy gesperrt sind, oder schlicht der Aufwand fehlt, das bei jedem betroffenen Gerät manuell durchzuführen.
Was sich wirklich lohnt — und für wen
Lass mich konkret sein. Ich würde Dev Drive in einem KMU für diese Konstellation empfehlen:
- Mindestens zwei Vollzeit-.NET-Entwickler auf dedizierten Entwickler-Notebooks
- Builds, die lokal länger als zwei Minuten dauern (darunter ist der Overhead des Umzugs nicht gerechtfertigt)
- NuGet-Cache-Größen über 5 GB (realistisch ab mittleren Projekten mit vielen Abhängigkeiten)
- Entwickler, die selbst Admin auf ihrem Gerät sind oder einen IT-Betreuer haben, der das einmalig ausrollt
Wenn diese vier Bedingungen zutreffen, ist der Aufwand überschaubar und der Gewinn real. In meinem Maschinenbauer-Beispiel: Build-Zeit von 4 Minuten auf 2:50 — nicht 30 %, aber 30 Sekunden pro Build summieren sich über den Tag.
Was Balliauw ausblendet
Balliauw beschreibt den Prozess aus der Perspektive eines erfahrenen Entwicklers, der sein eigenes Gerät verwaltet und sich einen Torx-T4-Schraubenzieher sucht, um eine neue SSD einzubauen. Das ist keine Kritik — das ist sein legitimer Anwendungsfall.
Im KMU sieht die Welt anders aus:
-
Kein eigenes SSD-Budget. Neue Hardware für vier Entwickler? Beantragung, Genehmigung, drei Monate warten. Oder gar nicht, weil "die Notebooks doch noch gut genug sind".
-
OneDrive ist kein Randproblem. Balliauw erwähnt es kurz als "deal breaker" für seinen first attempt. In KMUs ist OneDrive-for-Business oft die zentrale Dokumentenablage und von der IT aus Compliance-Gründen vorgeschrieben. Wenn Dev Drive mit OneDrive-Sync nicht funktioniert, ist das kein kleines Detail — das ist K.O.-Kriterium für viele Setups.
-
Defender-Policy greift von oben. Der Performance-Modus von Microsoft Defender für Dev Drive klingt gut. Aber in Umgebungen mit zentralem Endpoint-Management (Microsoft Defender for Endpoint, Intune-Policy) musst du prüfen, ob die lokale Performance-Mode-Konfiguration überhaupt greift — oder ob die zentrale Policy sie stillschweigend überschreibt. Das steht nirgends in Balliauws Artikel, weil er das nicht braucht.
Meine konkrete Empfehlung
Wenn du Entwickler in einem KMU bist: Probier zunächst die VHD-Variante. Du brauchst keine neue Hardware, kein Ticket an die IT-Abteilung für eine neue Partition. Erstelle eine virtuelle Festplatte mit 60-80 GB, formatiere sie als Dev Drive, verschiebe deinen NuGet-Cache dorthin (eine Umgebungsvariable: NUGET_PACKAGES), und miss deinen Build einmal vorher und einmal nachher. Wenn du weniger als 30 Sekunden gewinnst, lass es sein und investiere die Zeit anderswo.
Wenn du IT-Verantwortlicher in einem KMU bist: Bevor du Dev Drive ausrollst, prüfe drei Dinge: Erstens, ob Defender for Endpoint-Policies in deiner Umgebung den Performance-Modus erlauben. Zweitens, ob OneDrive-Sync bei euch auf Entwickler-Notebooks läuft und ob ihr das entkoppeln könnt. Drittens, ob die Entwickler überhaupt genug bauen, dass es einen Unterschied macht — ich habe KMU-Entwickler gesehen, die 80 % ihrer Zeit in YAML-Dateien verbringen und deren C#-Build zweimal am Tag läuft.
Wenn du Maartens Artikel gelesen hast und jetzt denkst, du musst eine neue SSD kaufen: Tu es nicht sofort. Teste erst mit VHD. Hardware-Investitionen für Entwickler-Performance sind in den meisten KMUs nicht das schlechteste Investment — aber erst, wenn du weißt, dass das Feature bei eurer Setup-Konstellation überhaupt funktioniert.
Der vollständige Original-Beitrag von Maarten Balliauw: Test-Driving Windows 11 Dev Drive for .NET
Technisch präzise, gut strukturiert, mit konkreten Konfigurationsschritten für NuGet, Maven, Gradle und npm — Pflichtlektüre, wenn du die Details umsetzen willst.
Ich schaue mir solche Setups regelmäßig in echten Mandaten an. Wenn du wissen willst, ob Dev Drive in eurer konkreten Windows-Umgebung Sinn ergibt — oder ob es andere Stellschrauben gibt, die mehr bringen — dann lass uns reden.
— Bernhard