Umgebungsvariablen
Umgebungsvariablen (Environment Variables) sind Schlüssel-Wert-Paare, die außerhalb des Quellcodes definiert werden und einer Anwendung zur Laufzeit zur Verfügung stehen. In Kombination mit Secret Management ermöglichen sie die sichere Trennung von Konfiguration und Code. Für Unternehmen bedeutet das: dieselbe Codebasis in verschiedenen Umgebungen, ohne sensible Daten im Repository.
Warum Umgebungsvariablen statt Konfigurationsdateien?
Umgebungsvariablen lösen ein zentrales Problem: Dieselbe Codebasis muss in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) mit unterschiedlichen Einstellungen laufen. Datenbankverbindungen, API -Schlüssel, Feature-Flags und Debug-Modi werden über Umgebungsvariablen gesteuert, ohne den Code zu ändern. Das verhindert, dass sensible Daten im Repository landen.
Umgebungsvariablen und Sicherheit
Umgebungsvariablen sind die einfachste Stufe des Secret Management . Für lokale Entwicklung werden sie in .env-Dateien definiert (die zwingend in .gitignore gehören). In Produktionsumgebungen werden sie über den Hosting-Provider, Docker-Secrets oder Secret-Manager gesetzt. Kritisch: .env-Dateien niemals committen, Umgebungsvariablen nicht in Logs oder Fehlermeldungen ausgeben.
Einsatz in Docker und CI/CD
In Containerisierung mit Docker werden Umgebungsvariablen über docker-compose.yml, .env-Dateien oder Docker Secrets gesetzt. In CI/CD -Pipelines werden sie als verschlüsselte Pipeline-Variablen (GitHub Secrets, GitLab CI Variables) definiert und zur Build- und Deploy-Zeit injiziert. Die Infrastructure as Code -Philosophie behandelt auch Konfiguration als versionierten, reproduzierbaren Code.
Häufige Fehler bei Umgebungsvariablen
Fehlende .gitignore-Einträge für .env-Dateien. Standardwerte für Secrets in der Codebasis. Keine Dokumentation der erforderlichen Variablen. Unterschiedliche Variablennamen zwischen Umgebungen. Keine Validierung beim Anwendungsstart – fehlende Pflicht-Variablen werden erst zur Laufzeit bemerkt. Ein .env.example-Template im Repository dokumentiert alle benötigten Variablen ohne sensible Werte.
So setzen wir es um
Jedes BTECH-Projekt enthält eine .env.example mit allen erforderlichen Variablen – dokumentiert, aber ohne sensible Werte. Django unterscheidet per DJANGO_SETTINGS_MODULE zwischen dev, staging und production. In unserer GitHub-Actions-Pipeline werden Credentials als verschlüsselte Secrets injiziert und nie in Logs ausgegeben. Angular nutzt environment.ts-Dateien, die beim Build-Prozess ersetzt werden. Docker Compose liest .env-Dateien automatisch – ein Setup, das Wartbarkeit und Sicherheit gleichermaßen stärkt.