Ein neues Django-Projekt fängt bei uns selten mit Businesslogik an. Erstmal kommen die üblichen Dinge: CI/CD-Pipeline, Docker, Linting, Security-Konfiguration, Multi-Environment-Settings. Das ist nicht nur zeitaufwendig, sondern damit auch eine potenzielle Fehlerquelle, weil jedes Projekt diese Entscheidungen neu trifft. Und mit jedem Projekt, das anders aufgesetzt wird, wächst die Fragmentierung im Unternehmen.
Mit cc-python haben wir ein im Unternehmen als Side-Project ein Open-Source Cookiecutter-Template entwickelt, welches diese Arbeit automatisiert. Ein Befehl generiert ein production-ready Django-Projekt mit allem, was dazugehört: Secure by default, mit CI/CD-Pipeline und einheitlicher Struktur über alle Projekte hinweg.
Das Problem: Jedes Projekt ist ein Einzelstück
Wer regelmäßig neue Django-Projekte aufsetzt, kennt die Checkliste: Custom User Model anlegen, Settings für verschiedene Umgebungen aufteilen, Docker konfigurieren, Pre-Commit Hooks einrichten, CI/CD-Pipeline schreiben, Security-Headers setzen. Die Liste ist lang und die Schritte sind bekannt. Und trotzdem schleichen sich jedes Mal kleine Abweichungen ein.
Das betrifft nicht nur die Geschwindigkeit beim Aufsetzen. Es betrifft die langfristige Wartbarkeit: Wenn jedes Projekt seine eigene Struktur hat, eigene Konventionen und eine individuell zusammengestellte Toolchain, wird der Wechsel zwischen Projekten teuer. Das Onboarding dauert länger, Code-Reviews werden aufwendiger, und Security-Konfigurationen fallen durch das Raster.
Die Lösung: Ein Template, das Erfahrung kodifiziert
cc-python ist ein Cookiecutter-Template, das ein vollständig konfiguriertes Django-Projekt erzeugt:
cookiecutter https://github.com/singularit-de/cc-python.git --directory django
Beim Generieren werden nur wenige Dinge abgefragt:
- Python-Version
- PostgreSQL-Version
- optional Django REST Framework
- Authentifizierung per E-Mail oder Username
Danach ist die Repo-Struktur fix, die Settings sind getrennt, Tooling ist drin, und die README führt einmal sauber durch die ersten Schritte:
git init --initial-branch=main
uv venv --allow-existing && source .venv/bin/activate
uv sync
pre-commit install
Es fehlt nur noch eine PostgreSQL-Datenbank und das Erstellen der .env-Datei anhand der mitgelieferten .env.example. Anschließend kann python manage.py runserver ausgeführt werden.
Was im generierten Projekt steckt
Moderne Toolchain
Wir setzen dabei bewusst auf ein paar Tools, die den Alltag spürbar vereinfachen:
- uv als Projekt- und Paketmanager (schnell, Lockfile, reproduzierbare Builds)
- Ruff für Linting + Formatierung (statt Flake8/isort/Black in Kombi)
- Pre-Commit Hooks, damit Checks nicht „optional“ sind
- Django-spezifische Werkzeuge wie:
- Django Debug Toolbar
- Django Extensions
- DRF Spectacular zur OpenAPI Schema-Generierung
Secure by Default
Sicherheit ist kein separater Schritt, der am Ende eines Projekts „noch gemacht werden muss“. In cc-python (und Django) ist sie Teil der generierten Defaults, und zwar von Anfang an und in jeder Umgebung.
Auf Applikationsebene:
- CSRF-Schutz und Clickjacking-Schutz aktiviert
- Richtig konfigurierte CORS für API-Schnittstellen
- Secret Key (und andere Zugangsdaten) aus Umgebungsvariablen
- Custom User Model von Anfang an korrekt aufgesetzt (denn eine nachträgliche Migration ist… kompliziert)
In Staging und Production:
- DEBUG = False
- SSL/TLS-Redirect konfiguriert (SECURE_SSL_REDIRECT)
- Sichere Cookie-Konfiguration: SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE, randomisierte Cookie-Namen
- HSTS mit Subdomain-Einbindung und Preload
- X-Content-Type-Options: nosniff
- Initiale Logging-Konfiguration für datenschutzkonformes loggen
In der Pipeline:
- manage.py check –deploy blockiert unsichere Deployments auf geschützten Branches
- Automatisierte Tests erkennen Fehler in Refactorings und verhindern wiederkehrende Bugs
- Pre-Commit Hooks erkennen versehentlich gepushte Secret Keys und nicht angewandtes Linting
- CI/CD-Variablen werden maskiert
Django Admin: Datenzugriff out of the box
Jedes Projekt kommt mit einem vorkonfigurierten Admin-Setup (u.a. via django-admin-interface für kundenspezifische Themes), Custom User Admin und ein paar Utilities wie ReadOnlyTabularInline. Zusätzlich ist WhiteNoise integriert, sodass Static Files in Staging und Production von Anfang an sauber ausgeliefert werden.
In vielen Projekten wollen wir sehr früh Daten in der DB inspizieren, filtern, manuell korrigieren oder User verwalten, vor allem wenn Data-Science-Workflows dranhängen. Das Django-Admin-Panel ist dafür oft die beste Wahl: Es liefert sofort eine funktionierende Oberfläche, ohne dass wir dafür erst ein eigenes Frontend bauen müssen.
CI/CD: Vom Push zum QA-System
Das generierte Projekt enthält eine vollständige GitLab CI/CD-Pipeline mit drei Stages:
- Lint — Ruff und Pre-Commit mit Dependency-Caching
- Test — Django-Tests gegen eine dedizierte PostgreSQL-Instanz
- Deploy — Automatisiertes Staging-Deployment via Docker Compose mit Deploy-Readiness-Checks
Die Pipeline ist auf unseren Workflow bei singularIT zugeschnitten: Nach dem ersten Push auf unser GitLab steht innerhalb von Minuten ein funktionierendes QA-System auf unserer Infrastruktur. Kein manuelles Deployment auf einen Testserver, keine „ich setz das mal schnell auf“-Tickets. Die Pipeline ist vorkonfiguriert, das Docker-Setup steht, die Umgebung wird automatisch auf unseren Systemen hochgefahren. Das QA-System wird von uns verwaltet und ist sofort für Kunden oder interne Tester erreichbar.
Vier Umgebungen, sauber getrennt
Die Settings sind modular aufgebaut: Eine base.py mit gemeinsamer Konfiguration, darauf aufbauend local.py (Entwicklung mit Debug Toolbar), test.py, staging.py (Security-Hardening) und production.py. Jede Umgebung erbt von der Basis und überschreibt nur, was nötig ist.
Standards statt Einzelstücke
Die technische Basis ist in einem Projekt damit gelegt. Der andere große Mehrwert liegt noch eine Ebene höher: cc-python schafft unternehmensweite Standards.
Mit cc-python wird die Entscheidung einmal getroffen und dann konsequent durchgesetzt:
- Tooling: In jedem Projekt identisch konfiguriert.
- Security: Dieselben Defaults, dieselben Checks.
- Struktur: Wer ein Projekt kennt, findet sich in jedem anderen sofort zurecht.
- Onboarding: Neue Teammitglieder lernen eine Struktur, nicht zehn.
Das reduziert nicht nur den Aufwand beim Aufsetzen neuer Projekte. Es reduziert den Aufwand bei allem, was danach kommt: Code-Reviews, Debugging, Wissenstransfer zwischen Teams, Wartung und Abwesenheitsvertretung.
Impact
Konkret bedeutet das für unsere Projektarbeit:
- Zeitersparnis: Ein manuelles Setup mit Docker, CI/CD, Security-Hardening und Multi-Environment-Settings dauert erfahrungsgemäß 1–2 Arbeitstage. Mit cc-python ist das initiale Setup in unter einer Stunde erledigt.
- Schnelle QA-Systeme: Nach dem ersten Push steht automatisch eine lauffähige Staging-Umgebung auf unserer Infrastruktur — ohne manuelles Deployment.
- Sofortiger Datenzugriff: Das Django Admin-Panel ist ab dem ersten Moment nutzbar — für Dateninspektion, Benutzerverwaltung und als schnelles Interface für Data-Science-Workflows.
- Security ohne Aufwand: Sicherheitsrelevante Konfiguration ist fester Bestandteil jedes Projekts.
- Unternehmensweite Konsistenz: Einheitliche Struktur, Tools und Konventionen über alle Projekte hinweg — weniger Reibung bei Onboarding, Reviews und Wartung.
- Weniger Fehler: Pre-Commit Hooks, automatisierte Tests und Deploy-Checks verhindern Fehler von Beginn an.
Ausprobieren
cc-python ist Open Source und auf GitHub verfügbar: github.com/singularit-de/cc-python
Voraussetzung ist lediglich eine aktuelle Installation von Cookiecutter und uv.