Überblick
Diese Referenzimplementierung demonstriert ein strukturiertes CI/CD-Promotionsmodell für Azure-basierte Anwendungen.
Der Fokus liegt nicht auf fachlicher Komplexität der Anwendung, sondern auf platform-orientierten Grundlagen:
- Build once, Promote über mehrere Umgebungen
- Infrastructure as Code mit Terraform
- Secretless Deployments mittels Managed Identity
- Klare Umgebungstrennung (Dev → Test → Prod)
- Freigabebasierte Deployment-Strategie
Das Projekt simuliert ein typisches Enterprise-Szenario, in dem gewachsene CI/CD-Strukturen konsolidiert und stabilisiert werden müssen.
Kontext
In vielen Azure-Umgebungen entstehen im Laufe der Zeit typische Muster:
- Hardcodierte oder pipelineverwaltete Secrets
- Manuelle Infrastrukturänderungen
- Direkte Deployments in Produktion
- Rebuild pro Umgebung statt Artifact-Promotion
- Geringe Nachvollziehbarkeit über Stages hinweg
Dieses Projekt zeigt eine strukturierte Alternative im Sinne professioneller Enterprise-Delivery-Modelle.
Architektur
Promotionsfluss
Build → Dev → Test → Prod
- Die Anwendung wird einmal gebaut.
- Das erzeugte Artifact wird über die Umgebungen hinweg promoted.
- Terraform provisioniert die Infrastruktur je Umgebung.
- Deployments nach Test und Produktion erfordern manuelle Freigaben.
Jede Umgebung enthält:
- Azure App Service (Linux)
- Azure Key Vault
- System Assigned Managed Identity
- Eigenes Terraform State
Es gibt keine geteilten Ressourcen oder Secrets zwischen Umgebungen.
CI/CD-Design
Die Pipeline ist in klar getrennte Stages unterteilt:
- Build
- Terraform Plan / Apply (je Umgebung)
- Applikationsdeployment
- Approval Gates (Test / Prod)
Zentrale Prinzipien:
- Unveränderliche Artifacts
- Promotion statt Neubuild
- Trennung von Infrastruktur- und Applikationsdeployment
- Wiederverwendbare Pipeline-Templates
- Health Checks nach Deployment
Diese Struktur unterstützt Nachvollziehbarkeit, Rollback-Fähigkeit und kontrollierte Release-Prozesse.
Infrastructure as Code
Terraform ist folgendermaßen strukturiert:
infrastructure/├── modules/├── environments/│ ├── dev│ ├── test│ └── prod└── bootstrap/
Architektonische Überlegungen:
- Modulare Ressourcen-Definitionen
- Remote State mit Locking (Azure Storage Backend)
- Strikte Umgebungstrennung
- Klare Naming-Konventionen
- Least-Privilege-Zuweisungen
Ziel ist ein reproduzierbares, nachvollziehbares Infrastrukturmodell.
Sicherheitsmodell
Das Sicherheitsdesign vermeidet statische Zugangsdaten vollständig.
Umgesetzte Muster:
- Managed Identity für Applikationsauthentifizierung
- Azure Key Vault für Secret Management
- RBAC-basierte Zugriffskontrolle
- Keine Secrets im Quellcode
- Keine Secrets im Pipeline-YAML
Die Anwendung nutzt DefaultAzureCredential, um lokale Entwicklung und Cloud-Betrieb ohne Credential-Duplikation zu ermöglichen.
Legacy-Vergleich
Der Branch legacy demonstriert typische Anti-Patterns, u.a.:
- Hardcodierte Zugangsdaten
- Monolithische Pipelines
- Keine Umgebungstrennung
- Direkte Produktionsdeployments
- Manuelle Infrastruktur
Der Vergleich verdeutlicht strukturelle Unterschiede zwischen ad-hoc-Setups und promotionsbasierten Delivery-Modellen.
Architektonische Überlegungen
Im Rahmen der Implementierung wurden insbesondere betrachtet:
- Terraform State Locking und Parallelität
- Abhängigkeitssteuerung bei Managed Identity und RBAC
- Strategie für Approval Gates
- Artifact-Versionierung und Nachvollziehbarkeit
- Isolierte Umgebungskonfiguration
Der Fokus lag auf Struktur und Klarheit – nicht auf Feature-Umfang.
Erkenntnisse
- Promotionsbasierte CI/CD-Strukturen erhöhen Nachvollziehbarkeit
- Modularisierte Infrastruktur reduziert Wartungskosten
- Managed Identity vereinfacht Credential-Management
- Klare Umgebungstrennung erhöht Betriebssicherheit
- Pipeline-Struktur ist entscheidender als Pipeline-Komplexität
Umfang
Diese Referenzimplementierung demonstriert:
- Azure Platform Engineering Grundlagen
- CI/CD-Architekturpatterns
- Infrastrukturautomatisierung
- Sicherheitsbewusstes Cloud-Design
Die Anwendung selbst ist bewusst schlank gehalten, um den Fokus auf die Plattformstruktur zu legen.
Status: Abgeschlossene Referenzimplementierung
Letzte Aktualisierung: Februar 2026