16. Jun 2025
Lesedauer 9 Min.
Weg mit den Hürden
GitHub Codespaces
Open-Source-Maintainer: Ihr könnt euch das Leben etwas einfacher machen.
dotnetpro
Open-Source-Software zu pflegen ist eine Herausforderung – und neue Mitstreiter für ein Projekt an Bord zu holen oft die Königsdisziplin. Treten dabei Probleme auf, liegt es meist nicht an mangelnder persönlicher Begeisterung, sondern an ganz realen Hürden: von Setup-Kämpfen bis zum Verstehen komplexer Codebasen. Diese haben dann zur Folge, dass es für neue Contributors oft nicht einfach ist, in ein bestehendes Projekt einzusteigen. Das kann einerseits in der Komplexität des Projekts selbst begründet sein, andererseits aber auch darin, dass es häufig einen hohen Aufwand bedeutet, alle benötigten Tools aufzusetzen. Zumindest für den letztgenannten Fall gibt jedoch es eine Lösung: Codespaces.Warum erzähle ich das? Ich selbst bin Co-Maintainer von bUnit, der Testing Library für Blazor. Ich habe immer wieder festgestellt, dass es wichtig ist, die Hürden für Contributors so niedrig wie möglich zu halten. In diesem Artikel gehe ich darauf ein, wie GitHub Codespaces dabei helfen kann und warum ich es auch privat für die Entwicklung einsetze.
Warum Codespaces?
GitHub Codespaces bietet eine cloudbasierte Entwicklungsumgebung, die direkt im Browser oder in Tools wie Visual Studio Code genutzt werden kann. Für Open-Source-Projekte bedeutet das, dass Entwickler nicht erst eine komplexe lokale Umgebung einrichten müssen – ein Codespace startet nach wenigen Klicks und bringt alles mit, was benötigt wird. Das ist besonders hilfreich, wenn jemand nur einen kleinen Bug beheben möchte oder eine Dokumentation anpassen will.Ein Beispiel: Man stelle sich vor, ein neuer Contributor will nur eben einen kleinen Fehler in der Doku fixen. Ohne Codespaces bedeutet das oft stundenlanges Setup für fünf Minuten Arbeit. Mit Codespaces? Zack, los gehts – direkt im Browser. Ohne Codespaces könnte das bedeuten, dass die Person erst eine vollständige Umgebung für bUnit einrichten müsste. Das könnten mehrere .NET-Versionen sein (wir supporten immer noch .netcoreapp3.1 bis .net9.0) und DocFX [1] für die Dokumentation.Ich möchte hier noch einmal betonen, dass dies in einem Browser läuft. Das heißt, man kann auf einem iPad mit angeschlossener Tastatur effektiv programmieren (wenn die Bildschirmgröße nicht für manche der limitierende Faktor ist), debuggen und live die eigene Applikation anschauen. Man braucht also nur eine stabile Internetverbindung, und es kann losgehen. Das „Heavy Lifting“ an Ressourcen passiert auf dem Remote-Rechner.Was kostet das?
GitHub Codespaces ist nicht kostenlos, aber GitHub stellt allen, die einen regulären Account nutzen, jeden Monat 120 CPU-Stunden kostenfrei zur Verfügung. Mit einem Pro-Account sind es 180 CPU-Stunden, und wer mehr Leistung benötigt, kann Codespaces mit bis zu 32 Kernen ausstatten (Bild 1).
GitHub-Kosten: Übersicht der Codespaces-Abrechnung mit Inklusivminuten und kostenpflichtigen Anteilen (Bild 1)
Autor
In der Praxis sind die 120 CPU-Stunden pro Monat jedoch oft ausreichend, vor allem für gelegentliche Beiträge. Die Abrechnung erfolgt über den Account des Contributors. Als Organisation hat man hier noch ganz andere Möglichkeiten.Aber was sind „CPU-Stunden“? Die Rechnung ist ganz einfach: Nutzt man einen Dev Container mit 32 Kernen für eine Stunde, dann hat man 32 CPU-Stunden verbraucht. Das heißt, in der günstigsten Konfiguration (Dual-Core) hat man 60 Stunden „Zeit“. Aus eigener Erfahrung empfehle ich eher, auf vier oder noch besser acht Kerne zu gehen. Bei acht Kernen hat man immer noch 15 Stunden pro Monat Dev Container verfügbar und schont dabei die eigenen Nerven.Mehr Infos findet man in der GitHub-Dokumentation zu den Codespaces-Gebühren unter [2].
Codespace für bUnit
Um einen Dev Container einzurichten, erstellt man entweder im .devcontainer-Verzeichnis im Projekt eine devcontainer.json-Datei oder nutzt die grafische Oberfläche auf GitHub, wie in Bild 2 zu sehen.
Dev-Container-Konfiguration: Die GitHub-Oberfläche zum Erstellen und Konfigurieren eines neuen Dev Containers (Bild 2)
Autor
Für bUnit haben wir den folgenden Inhalt, auf den ich Stück für Stück eingehen werde:
// For format details, see https://aka.ms/devcontainer.
// json. For config options, see the README at:
// https://github.com/devcontainers/templates/tree/main/
// src/dotnet
{
"name": "Full",
// Or use a Dockerfile or Docker Compose file. More
// info: https://containers.dev/guide/dockerfile
"image": "mcr.microsoft.com/dotnet/sdk:9.0-preview",
"features": {
"ghcr.io/devcontainers/features/dotnet:2": {
"version": "latest",
"additionalVersions": "7.0,6.0,5.0,3.1"
}
},
// Features to add to the dev container.
// More info: https://containers.dev/features.
// "features": {},
// Configure tool-specific properties.
"customizations": {
"vscode": {
"extensions": [
"ms-dotnettools.csdevkit",
"yzhang.markdown-all-in-one",
"vscode-icons-team.vscode-icons",
"me-dutour-mathieu.vscode-github-actions"
]
}
},
"postCreateCommand":
"bash .devcontainer/post-install.sh"
// Uncomment to connect as root instead.
// More info: https://aka.ms/dev-containers-non-root.
// "remoteUser": "root"
}
Im Grunde beschreibt die Datei, wie der Docker-Container am Ende aussehen wird, den GitHub für uns hochfährt. Dabei bezeichnet image das Basisimage, welches ein beliebiges Docker-Image sein kann. features kann man sich wie zusätzliche Schichten vorstellen, die dem Container hinzugefügt werden. In bUnit ist es so, dass wir bis heute alles ab .netcore3.1 bis .net9.0 unterstützen.Auf den ersten Blick ist dies vermutlich sehr verwirrend. Wenn man wie in Bild 3 gezeigt einen neuen Codespace erstellt, wird die devcontainer.json direkt miterstellt. Der Unterschied zu der oben gegebenen Datei: Man startet mit einem „universellen“ Docker-Image (mcr.microsoft.com/devcontainers/universal:2). Dies ist vor allem dann nützlich, wenn man mehrere Sprachen und Tools in einem Projekt verwendet. In bUnit ist ganz klar, dass
es sich um .NET handelt. Daher sieht man im gegebenen Beispiel auch, dass es sich um ein
.NET-9-Vorschau-Image handelt.
es sich um .NET handelt. Daher sieht man im gegebenen Beispiel auch, dass es sich um ein
.NET-9-Vorschau-Image handelt.
Codespace-Erstellung: Alternative Ansicht zur Konfiguration und Erstellung eines Dev Containers auf GitHub (Bild 3)
Autor
Features ergänzen das Ganze. So kann man ohne Weiteres Tools, CLIs und weiteren Support für Sprachen hinzufügen. Die komplette Liste der Optionen lässt sich auf der offiziellen Dokumentation unter [3] finden.Hier ein kleines Beispiel, das dem universellen Image noch das .NET CLI und den Node Package Manager hinzufügt.
{
"name": "DevContainer",
"image":
"mcr.microsoft.com/devcontainers/universal:2",
"features": {
// Wir wollen noch das .NET SDK und Tooling
// installieren – in der letzten stabilen
// Version und .NET 7.0
"ghcr.io/devcontainers/features/dotnet:2": {
"version": "latest",
"additionalVersions": "7.0"
},
"ghcr.io/devcontainers/features/node:1": {}
},
Viele der Features erlauben noch eine weitere Konfiguration: Wie im gerade gezeigten Beispiel lassen sich noch die .NET-Versionen bestimmen. Informationen dazu können Sie dem Dokument unter [3] entnehmen. Dieses Dokument verlinkt weiterführende Informationen, für das .NET CLI im Beispiel wären diese unter [4] zu finden. Wie man sieht, lassen sich hier schon sehr viele Aspekte vorkonfigurieren.Wer Codespaces direkt im Browser via GitHub verwendet, wird feststellen, dass dies wie Visual Studio Code aussieht. Und genau das ist es auch. Daher bietet ”customizations” uns auch die Möglichkeiten, mit ”postCreateCommand” schon Extensions für Visual Studio Code zu installieren. Wenn der Docker-Container erstellt wurde, erlaubt uns GitHub, ein beliebiges Skript auszuführen. Da unser Basis-Image auf Linux basiert, handelt es sich hier um ein Shellskript:
#/bin/bash
# Install docfx (should be aligned with docs-deploy.yml)
dotnet tool install --global docfx --version 2.74.1
# Trust dotnet developer certs
dotnet dev-certs https --check --trust
Wir installieren das DocFX-Tool und erlauben Developern, Zertifikate zu benutzen. Es handelt sich hier um ein voll funktionsfähiges Betriebssystem. Klar, das ist in einem Container, aber wir haben alle Möglichkeiten, die wir auch in einer regulären VM oder einem regulären PC vorfinden. Da es sich um ein Ubuntu-System handelt, können wir auch ohne Weiteres Pakete installieren:
# Install mkdocs
apt install -y mkdocs
Genau diesen Ansatz verwende ich in einem meiner anderen Open-Source-Projekte. Dieses Vorgehen bietet unglaubliche Flexibilität und erlaubt es dem Entwickler, die Umgebung komplett an die eigenen Wünsche anzupassen.Das bringt uns zum nächsten Punkt: Wir wissen, dass es sich hier um ein vollumfängliches Visual Studio Code handelt.
Das volle Potenzial von Codespaces und Visual Studio Code nutzen
In Visual Studio Code kann man sogenannte Tasks definieren. Tasks können zum Beispiel kleinere Skripte sein, die repetitive Aufgaben vereinfachen – so zum Beispiel auch das Erstellen der Dokumentation. Aufgaben oder „Tasks“ werden in .vscode/tasks.json definiert.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Serve Docs (Without Build)",
"type": "shell",
"command":
"docfx metadata docs/site/docfx.json &&
docfx docs/site/docfx.json --serve"
},
{
"label": "Serve Docs (
With Build for API Documentation)",
"type": "shell",
"command": "dotnet build -c Release &&
docfx metadata docs/site/docfx.json &&
docfx docs/site/docfx.json --serve"
},
{
"label": "Run all tests (Release Mode)",
"type": "shell",
"command": "dotnet test -c Release"
}
]
}
Dies sind einfache Skripte, die sich direkt aus dem Editor heraus ausführen lassen (Bild 4).
Task Runner: Die Kommando-Palette in Visual Studio Code zum Starten benutzerdefinierter Aufgaben im Codespace (Bild 4)
Autor
Wie in Visual Studio Code gewohnt geht dies via Kommando-Palette. Führen wir einen Task aus, wie zum Beispiel das Erstellen und Anzeigen der Dokumentation, so poppt ein kleines Fenster auf, das uns direkt sagt, dass eine Anwendung auf einem Port Nachrichten sendet (Bild 5). Klicken wir dann auf Open in Browser, sehen wir die komplette Dokumentation, ohne dass der Nutzer auch nur ein einziges Tool (neben einem Browser) installiert haben muss (Bild 6).
Port-Weiterleitung: Automatische Benachrichtigung über geöffnete Ports mit der Option, diese direkt im Browser zu öffnen (Bild 5)
Autor
Live-Dokumentation: Die bUnit-Dokumentation wird im Codespace generiert und kann sofort im Browser betrachtet werden (Bild 6)
Autor
Aber natürlich endet die Synergie hier nicht. Da es sich um ein reguläres Visual Studio Code handelt, können wir auch Code debuggen und laufen lassen oder Features wie Live Share nutzen, um Code interaktiv mit Kollegen zu teilen.
Rider
Natürlich lässt sich all dies auch in anderen Tools verwenden, zum Beispiel in JetBrains Rider, das vor Kurzem für Open-Source- und nichtkommerzielle Projekte kostenlos geworden ist [5], siehe Bild 7 und Bild 8.
Rider-Integration: JetBrains Rider kann sich für eine vollwertige IDE-Erfahrung direkt mit dem Dev Container verbinden (Bild 7)
Autor
JetBrains Rider zeigt detaillierte Informationen zur Auslastung des Dev Containers (Bild 8)
Autor
Andere Szenarien
Im Open Source Development können Codespaces ihre Stärken ausspielen. Dies lässt sich auch weiterdenken. Die Grundidee ist, die Onboarding-Zeit so gering wie möglich zu halten. Firmen könnten Codespaces nutzen, um neuen Mitarbeitern eine Umgebung bereitzustellen, ohne dass diese sich um die Einrichtung kümmern müssen. Tools wie Visual Studio Code oder Rider können diese Codespaces aber auch mithilfe einer lokalen Docker-Installation lokal laufen lassen. Dies hat den Vorteil, dass man keine permanente Internetverbindung braucht und die Kosten vorher abschätzen kann.Aber hier endet das Ganze noch nicht. Unabhängig davon, ob Codespaces für die Open-Source-Entwicklung oder innerhalb einer Firma genutzt werden, bieten sich weitere Vorteile an, die automatisch inbegriffen sind:Live Share:Bietet (wie der Name bereits erahnen lässt) die Möglichkeit, den Inhalt des Bildschirms inklusive Cursor-Position und selektiertem Text mit einem oder mehreren Teilnehmern zu teilen. Dies eignet sich perfekt für virtuelle Pair-Programming-Sessions. In bUnit nutzen wir dies, um es dem Gegenüber zu erleichtern, dem aktuellen Geschehen zu folgen. Je nach Einstellung kann das Gegenüber auch Text editieren oder markieren. Dies ist bei Weitem effizienter, als einfach den Bildschirm via Teams oder Slack zu teilen (Bild 9).
Live Share: Visual Studio Code ermöglicht Echtzeit-Kollaboration und gemeinsames Coden direkt im Codespace (Bild 9)
Autor
Dies lässt sich wunderbar mit dem nächsten Aspekt verbinden:Pull Request Reviews: Wer kennt es nicht: Pull Requests reviewen kann stressig sein und ist für „First Time Contributors“, wie es GitHub so schön ausdrückt – also Leute, die zum ersten Mal bei einem Repository einen Pull Request erstellen oder ein Issue eröffnen – oft eine Quelle von Frust. Missverständnisse sind ganz natürlich, und vor allem sind sogenannte Nitpicks oft irritierend für alle Beteiligten (Bild 10).
PR-Review: Die GitHub-Extension in Visual Studio Code vereinfacht das Überprüfen und Bearbeiten von Pull Requests (Bild 10)
Autor
Codespaces erlaubt es dank Visual Studio Code sehr einfach, Pull Request zu editieren, zu kommentieren oder sogar eigene Commits auf den Branch des Erstellers zu pushen (wenn derjenige dies erlaubt). Das bedeutet Schluss mit Nitpicks oder ewig langen Kommentaren: Bei Bedarf kann der Maintainer eine helfende Hand reichen und Teile selbst übernehmen. Aus Erfahrung sorgt dies für wesentlich weniger Reibung und Frustration auf beiden Seiten.Die meisten Entwickler kennen das Problem: Die Pull-Request-Ansicht auf Plattformen wie GitHub oder Bitbucket wirkt häufig unzureichend, gerade wenn es darum geht, tiefer in den Code einzutauchen. Essenzielle Hilfen, die man aus der eigenen IDE gewohnt ist, fehlen in vielen Fällen – sei es etwa die Code-Dokumentation, die in einer lokalen Entwicklungsumgebung automatisch angezeigt wird, oder die Möglichkeit, schnell zu Symbolen zu springen, um den Kontext besser zu verstehen.Hier spielt GitHub Codespaces seine Stärke als vollständige IDE aus. Bei nichttrivialen Pull Requests nutze ich meist einen Codespace (oder klone den Pull-Request-Branch lokal). Natürlich lässt sich dies auch mit der Live-Share-Funktionalität kombinieren. Und das alles in einem Browser.
Limitationen
Trotz seiner vielen Vorteile hat Codespaces auch einige Einschränkungen. Eine der größten ist die Abhängigkeit von einer stabilen Internetverbindung. Codespaces ist cloudbasiert und läuft auf Servern von Drittanbietern (zum Beispiel Azure).Auch die Kosten der Nutzung sollten im Auge behalten werden. Die monatlich kostenlosen 120 CPU-Stunden reichen für gelegentliche Beiträge und kleinere Projekte meist aus. Doch bei intensiver Nutzung oder bei Bedarf an mehr CPU-Kernen steigt der Verbrauch schnell an – und damit auch die Kosten. Besonders für langfristige Projekte könnte sich das summieren.Ein oft diskutierter Punkt ist der Datenschutz. Zwar ist die Kommunikation Ende-zu-Ende-verschlüsselt, und GitHub setzt alles daran, Container sicher zu isolieren. Doch am Ende handelt es sich um eine Cloud-Instanz, die eben nicht lokal läuft. Gerade in sensiblen Projekten oder wenn spezielle Compliance-Anforderungen bestehen, bleibt der Einsatz von Codespaces für manche Entwickler eine Hürde, da sie volle Kontrolle und Sicherheit auf ihren eigenen Rechnern bevorzugen.Schließlich bleibt auch die Anpassungsfähigkeit von Codespaces begrenzt: Für Standard-Setups und viele Open-Source-Projekte bietet die Umgebung eine hohe Flexibilität, doch bei sehr spezialisierten Anforderungen – zum Beispiel GPU-Rendering oder Hardware-nahen Aufgaben – stößt die Cloud-Umgebung an ihre Grenzen. Hier könnte ein lokales Setup die bessere Wahl sein.Fazit
GitHub Codespaces ist ein mächtiges Tool, das die Einstiegshürde für neue Contributors deutlich senkt und euch als Maintainer entlastet. Durch die Bereitstellung einer vorgefertigten Umgebung sorgt ihr dafür, dass sich Entwickler schneller in euer Projekt einbringen und produktiv arbeiten können – ohne sich erst mit Setup-Problemen beschäftigen zu müssen. Nutzt diese Möglichkeit, und gestaltet euren Open-Source-Beitrag für die Community durch den Einsatz von GitHub Codespaces einfacher und effektiver!Fussnoten
- DocFX, https://dotnet.github.io/docfx/
- About billing for GitHub Codespaces, http://www.dotnetpro.de/SL2506-07Codespaces1
- Dev-Container-Dokumentation, https://containers.dev/features
- Dotnet CLI als Dev-Container-Feature, http://www.dotnetpro.de/SL2506-07Codespaces2
- JetBrains-Blog, WebStorm and Rider Are Now Free for Non-Commercial Use, http://www.dotnetpro.de/SL2506-07Codespaces3
