Eine gut durchdachte Projektstruktur in deinem Versionskontrollsystem ist entscheidend, um neue Mitarbeitende schnell einzuarbeiten und bestehenden Mitarbeitenden eine klare Orientierung zu bieten. Die Strukturierung sollte die verschiedenen Bereiche deines Projekts abbilden, wie z.B. Frontend, Backend, Cloud, On-Premise oder Mobile. Darüber hinaus hilft eine saubere Struktur, nicht nur den Code zu organisieren, sondern auch automatisierte Tests, Konfigurationen, Skripte, Pipelines, Infrastruktur und Dokumentation sauber zu strukturieren.
Die Größe deines Projekts spielt eine wichtige Rolle bei der Wahl der Struktur. Bei größeren oder mehreren Projekten in einem Mono-Repository mit unterschiedlichen Anwendungen (z.B. Frontend, Backend, Datenbanken oder andere Services) kann es sinnvoll sein, diese Projekte weiter zu untergliedern. Bei kleineren Projekten reicht oft eine einfachere Struktur auf der obersten Ebene.
David Fowler von Microsoft hat vor längerem eine Vorlage für .NET-Projekte veröffentlicht, die eine klare Trennung auf der obersten Ebene vorsieht:
| Ordner | Beschreibung |
|---|---|
| src | Quellcode der Anwendungen |
| tests | Testprojekte |
| docs | Dokumentationen |
| libs | Bibliotheken |
| … | Diverse Dateien mehr… |
Auf der obersten Ebene befinden sich globale Konfigurationen und Abhängigkeitsmanager wie NuGet oder npm, sowie Skripte zum Kompilieren der Lösung und eine README-Datei, die die Projektstruktur erklärt und Anweisungen zum Kompilieren und Debuggen gibt.
Die Empfehlung für eine minimale Ordnerstruktur lautet:
| Ordner | Beschreibung |
|---|---|
| eng/ | Pipelines |
| docs/ | Dokumentation |
| src/ | Anwendungen und Testprojekte |
| .editorconfig | Editor-Konfigurationen für Styling |
| .gitignore | Git Ignore-Datei |
| .gitattributes | Git Attribute-Datei |
| LICENSE | Lizenzdatei |
| README.md | Projektbeschreibung und zum Entwickeln |
| Solution.sln | Solution für .NET-Projekte |
Diese Struktur ist flexibel und kann bei Bedarf erweitert werden, z.B. um Samples, Skripte oder Ähnliches. Wichtig ist, dass die Struktur dokumentiert ist, damit alle Entwickler:innen wissen, wo sie was ablegen und finden können, ohne dass die oberste Ebene unübersichtlich wird. Dies kann direkt in der README.md-Datei erfolgen mit erweiterter Dokumentation im docs-Ordner.
Was die einzelnen Dateien machen und wie die einzelnen Ordner im Detail nochmal strukturiert werden können, erkläre ich in einem separaten Beitrag.
In einem Mono-Repository mit mehreren Projekten kann es sinnvoll sein, die Projekte in Unterordnern zu gruppieren und für jedes die minimale Ordnerstruktur anzuwenden. So behältst du den Überblick und kannst die Projekte getrennt voneinander entwickeln und verwalten, während sie im selben Repository liegen und auch globale Konfigurationen teilen.
Die Empfehlung für eine erweiterte Ordnerstruktur für mehrere Projekte lautet:
| Ordner | Beschreibung |
|---|---|
| eng/ | Pipelines Templates oder Governance Pipelines |
| docs/ | Allgemeine Dokumentation |
| projects/ | Anwendungen und Testprojekte |
| .editorconfig | Globale Editor-Konfigurationen für Styling |
| .gitignore | Globale Git Ignore-Datei |
| .gitattributes | Globale Git Attribute-Datei |
| LICENSE | Globale Lizenzdatei |
| README.md | Globale Beschreibung des Repositories |
Innerhalb des projects-Ordners besitzt jedes Teilprojekt einen eigenen Ordner. In diesen Unterordnern gilt dann wieder die minimale Ordnerstruktur.
Je nach Projekt können Abweichungen in der Benennung und Struktur sinnvoll sein. Beispielsweise können Pipelines in einem Ordner wie build oder eng (Engineering) liegen, oder bei GitHub Actions im Ordner .github. Testprojekte können separat in einem eigenen tests-Ordner liegen, um die App-Struktur nicht zu überladen und spezielle Eigenschaften für alle Testprojekte zentral zu konfigurieren.
Die Empfehlung ist sehr minimal und je nach Art der Anwendungen kann es auch beliebig erweitert werden, wie z.B. eine Directory.Build.props im Root-Verzeichnis für .NET-Projekte, eine package.json im Root-Verzeichnis für Frontend-Projekte oder ähnliches.
Ein Beispiel kannst du dem Open Space Planner entnehmen. Dieses ist auf eine komplexere Projektstruktur ausgelegt.
Wie strukturierst du deinen Code und deine Projekte im Source Control? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Weitere Artikel zu ähnlichen Themen.
