End-to-End-Entwicklerworkflow

Ein moderner Azure-Entwicklerworkflow verbindet Quellcodeverwaltung, CI/CD, Containerinfrastruktur und Observability zu einer nahtlosen Inner Loop – vom Code-Commit bis zur beobachtbaren Produktionsumgebung. Die zentralen Komponenten sind: GitHub (Quelle), GitHub Actions (Build- und Bereitstellungspipeline), Azure Container Registry (Imagespeicher), Azure Container Apps (Laufzeitumgebung) und Application Insights (Observability). Jede Änderung gelangt innerhalb weniger Minuten automatisch vom Entwicklergerät in die Produktion, wobei in jedem Schritt Qualitätssicherungen greifen.

Organisieren Sie Ihren Code in einem GitHub-Repository und verwenden Sie eine trunk-basierte Entwicklungsstrategie oder GitFlow. Für die meisten Microservices reduziert die trunk-basierte Entwicklung (kurzlebige Feature-Branches, die täglich in main zusammengeführt werden) Integrationskonflikte und hält die Pipeline einfach. Verwenden Sie Branch-Schutzregeln für main, um vor dem Zusammenführen Reviews von Pull Requests und erfolgreich durchlaufene CI-Prüfungen zu verlangen. Eine CODEOWNERS-Datei stellt sicher, dass Änderungen an kritischen Diensten die Genehmigung der zuständigen Seniorentwickler des jeweiligen Teams erfordern.

Die CI-Pipeline wird bei jedem Pull Request ausgeführt. Ein typischer Workflow sieht folgendermaßen aus: Code auschecken → Abhängigkeiten wiederherstellen → Komponententests ausführen → Integrationstests ausführen → Docker-Image erstellen → in Azure Container Registry pushen. Das Image wird zur Rückverfolgbarkeit mit dem Git-Commit-SHA getaggt. Verwenden Sie die OIDC-basierte Authentifizierung von GitHub Actions bei Azure (über eine föderierte Identität), um das Speichern von Geheimnissen für Azure-Dienstprinzipale in GitHub zu vermeiden – eine Entsprechung zur verwalteten Identität für CI-Pipelines.

Nachdem die CI-Pipeline bei einem Merge in main erfolgreich war, stellt die CD-Pipeline automatisch in der Stagingumgebung bereit. Die Pipeline aktualisiert das Image-Tag der Container App auf den SHA des neu erstellten Images, wartet, bis die neue Revision fehlerfrei ist, und führt Smoke-Tests für die Staging-URL aus. Smoke-Tests prüfen, ob wichtige API-Endpunkte die erwarteten Antworten liefern. Schlagen die Smoke-Tests fehl, führt die Pipeline ein Rollback durch, indem sie den Ingress-Datenverkehr ohne manuellen Eingriff wieder auf die vorherige Revision umleitet.

Nach der Validierung in der Stagingumgebung hält die CD-Pipeline an einer Genehmigungsschranke an. Mit den Umgebungsschutzregeln von GitHub Actions können Sie erforderliche Prüfer für die production-Umgebung konfigurieren. Die Pipeline sendet eine Slack-Benachrichtigung an den Bereitschaftsingenieur. Dieser prüft die Testergebnisse der Stagingumgebung, die Änderungen und alle offenen Vorfälle, bevor er die Genehmigung erteilt. Erst nach der Genehmigung fährt die Pipeline mit der Bereitstellung desselben Image-SHA in der Produktion fort. Dieser Schritt mit menschlicher Kontrolle ist für stark frequentierte oder regulierte Dienste entscheidend.

Nach der Bereitstellung in der Produktion bietet Application Insights Einblick in Echtzeit. Das App-Insights-SDK (oder die automatische Instrumentierung für unterstützte Laufzeitumgebungen) erfasst: Anforderungsraten, Fehlerraten und Latenz (die drei Golden Signals), Abhängigkeitsaufrufe (an Datenbanken, Service Bus und andere APIs) sowie Ausnahmen mit vollständigen Stacktraces. Die Application Map visualisiert, wie Dienste einander aufrufen, und hebt hervor, welche Abhängigkeiten am stärksten zu Fehlern oder Latenz beitragen.

Verwenden Sie Application Insights Annotations, um Bereitstellungsereignisse in Ihren Metrikdiagrammen zu markieren. Wenn eine Release-Annotation erstellt wird (über die GitHub-Actions-Aktion azure/appinsights-annotation), erscheint sie als vertikale Linie in allen App-Insights-Metrikdiagrammen. Dadurch ist sofort erkennbar, ob ein Latenzanstieg oder eine erhöhte Fehlerrate mit einer kürzlich erfolgten Bereitstellung zusammenhängt. Das verkürzt die mittlere Zeit bis zur Diagnose (MTTD) während Vorfällen erheblich.

Für besonders ausfallsichere Pipelines sollten Sie ein automatisches Rollback implementieren. Nach der Bereitstellung in der Produktion wartet die Pipeline 10 Minuten und fragt Application Insights nach der Fehlerrate ab. Überschreitet die Fehlerrate einen konfigurierbaren Schwellenwert (z. B. >5 %), führt die Pipeline automatisch ein Rollback durch, indem sie den Ingress-Datenverkehr der Container App zu 100 % auf die vorherige Revision umleitet. Dieses Muster der progressiven Bereitstellung begrenzt die Auswirkung einer fehlerhaften Bereitstellung und ermöglicht Teams auch bei komplexen oder sensiblen Änderungen eine sichere Bereitstellung.

Entwickler sollten den gesamten Stack lokal ausführen und testen können, ohne eine Verbindung zu Azure-Produktionsressourcen herzustellen. Verwenden Sie Azure Storage Emulator (Azurite) für die lokale Blob- und Warteschlangenspeicherung, den Cosmos DB Emulator für lokale Datenbanktests und den Service Bus Emulator für lokale Nachrichtenübermittlung. Die Umgebungsvariable AZURE_ENVIRONMENT=local kann DefaultAzureCredential so umschalten, dass Verbindungszeichenfolgen für Emulatoren verwendet werden, während derselbe Code in Azure eine verwaltete Identität nutzt. Docker Compose orchestriert alle lokalen Abhängigkeiten mit einem einzigen docker compose up.

Integrieren Sie Sicherheit in jede Phase des Entwicklerworkflows: Dependabot sucht in Pull Requests nach anfälligen Abhängigkeiten; GitHub Advanced Security (Codescanning mit CodeQL) erkennt Schwachstellen wie SQL-Injection und fest codierte Geheimnisse; Microsoft Defender for DevOps lässt sich in GitHub integrieren, um Azure-Sicherheitsempfehlungen neben Codeänderungen anzuzeigen; und das ACR Defender-Schwachstellenscanning prüft Container-Images nach jedem Push auf CVEs in Betriebssystem und Anwendungsschicht. Sicherheitsergebnisse werden als Kommentare in Pull Requests angezeigt und können daher vor dem Zusammenführen behoben werden.

Der vollständige Entwicklerworkflow ist eine kontinuierliche Feedbackschleife: Ein Entwickler führt einen Code-Commit durch, CI erstellt und testet das Container-Image, das Image wird mit dem Commit-SHA als Tag in ACR gepusht, CD stellt es in der Stagingumgebung bereit und führt Smoke-Tests aus, ein Mensch genehmigt die Bereitstellung in der Produktion, die Pipeline stellt das Image in der Produktion bereit und erstellt eine Release-Annotation, und Application Insights überwacht die Fehlerraten mit automatischem Rollback, wenn Schwellenwerte überschritten werden. Infrastructure as Code (Bicep oder Terraform) im selben Repository stellt sicher, dass Pipeline, Container App und Überwachungskonfiguration zusammen mit dem Anwendungscode versionskontrolliert werden.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Der End-to-End-Entwicklerworkflow verbindet die Quellcodeverwaltung mit GitHub, GitHub Actions CI/CD, Azure Container Registry, Container Apps und Application Insights; Release-Annotationen setzen Bereitstellungen mit Metrikänderungen in Beziehung und ermöglichen so eine schnellere Diagnose von Vorfällen; und ein automatisches Rollback auf Grundlage von Fehlerratenabfragen verringert die Auswirkungen fehlerhafter Bereitstellungen. Als Nächstes beginnen wir mit der Prüfungsvorbereitung und einer umfassenden Wiederholung von Cloudkonzepten und Azure-Architektur.