Kontinuierliche Bereitstellung in Azure

Continuous Deployment (CD) stellt jede Änderung, die die CI-Tests besteht, ohne manuelles Eingreifen automatisch in der Produktion bereit. Continuous Delivery ist die abgeschwächte Variante: Die Bereitstellung bis zu einer Staging-Umgebung wird automatisiert, vor der Produktion ist jedoch ein menschliches Genehmigungstor erforderlich. Beide Praktiken basieren auf derselben Pipelineinfrastruktur. In Azure Pipelines wird CD implementiert, indem nach der CI-Stage Bereitstellungs-Stages hinzugefügt werden, die je nach Bedarf auf Azure-Umgebungen mit Genehmigungstoren abzielen.

Eine vollständige CI/CD-Pipeline umfasst mindestens drei Stages: Build (kompilieren, testen, Artefakt veröffentlichen), Bereitstellung in Staging (Artefakt in einem Nichtproduktionsslot bereitstellen) und Bereitstellung in der Produktion (Slot austauschen oder nach Genehmigung bereitstellen). Stages geben das Artefakt über den Speicher für Pipelineartefakte weiter. Die Staging-Stage führt Integrations- oder Smoke-Tests automatisch aus; die Produktions-Stage wartet vor dem Fortfahren auf eine manuelle Genehmigung.

Verwenden Sie für Bereitstellungs-Stages deployment-Jobs und keine normalen job-Jobs. Bereitstellungsjobs unterstützen Bereitstellungsstrategien (runOnce, rolling, canary), erfassen den Bereitstellungsverlauf pro Umgebung und müssen auf Azure-DevOps-Umgebungen verweisen. Eine Umgebung erfasst, welche Pipelineausführungen darin bereitgestellt wurden und welche Version derzeit aktiv ist. Außerdem stellt sie Genehmigungstore, Prüfungen und den Status der Ressourcenintegrität in einem einzigen Dashboard bereit.

Der Task AzureWebApp@1 stellt eine Webanwendung in Azure App Service bereit. Er unterstützt die Bereitstellung in einem bestimmten Slot (z. B. Staging) sowie die Bereitstellung von ZIP-Paketen, Docker-Images oder JAR-/WAR-Dateien. Nach der Bereitstellung in einem Staging-Slot verwenden Sie den Task AzureAppServiceManage@0, um den Staging-Slot in die Produktion zu tauschen – das ist das bevorzugte Bereitstellungsmuster ohne Ausfallzeit für App Service.

Führen Sie nach der Bereitstellung in Staging Smoke-Tests aus – eine minimale Testsuite, die überprüft, ob die Bereitstellung erfolgreich war und die Anwendung korrekt antwortet. Smoke-Tests rufen typischerweise wichtige API-Endpunkte auf und überprüfen die erwarteten Statuscodes und Antwortinhalte. Wenn Smoke-Tests fehlschlagen, stoppt die Pipeline vor dem Tausch in die Produktion oder vor der Genehmigungsanforderung. So wird verhindert, dass eine fehlerhafte Version die Benutzer erreicht.

Fügen Sie Azure-DevOps-Umgebungen Genehmigungstore hinzu, um vor dem Fortsetzen einer Bereitstellung eine manuelle Freigabe zu verlangen. Öffnen Sie die Umgebungseinstellungen und fügen Sie unter „Approvals“ Genehmigungen hinzu – legen Sie die Benutzer oder Gruppen fest, die genehmigen müssen. Wenn die Pipeline einen Bereitstellungsjob erreicht, der auf diese Umgebung zielt, wird sie angehalten und sendet eine E-Mail-Benachrichtigung. Genehmigende Personen können die Bereitstellungsdetails im Azure-DevOps-Portal oder über den Link in der Benachrichtigungs-E-Mail anzeigen und genehmigen oder ablehnen.

Stellen Sie containerisierte Anwendungen mit dem Task KubernetesManifest@0 in AKS bereit. Dieser Task wendet Kubernetes-YAML-Manifeste auf den Cluster an und unterstützt standardmäßig imagePullSecrets und Canary-Bereitstellungen. Stellen Sie über eine in Azure DevOps konfigurierte Kubernetes-Dienstverbindung eine Verbindung mit dem AKS-Cluster her. Der Task verwendet intern kubectl apply und wartet, bis das Rollout abgeschlossen ist, bevor der Step als erfolgreich markiert wird.

Versehen Sie Container-Images mit der Build-ID ($(Build.BuildId)) oder dem Git-Commit-SHA ($(Build.SourceVersion)), damit Sie jederzeit einen laufenden Container auf genau die Codeversion zurückführen können, aus der er erstellt wurde. Vermeiden Sie das Tag latest in der Produktion – Kubernetes cached es und ruft die neue Version möglicherweise nicht ab. Speichern Sie das spezifische Image-Tag als Pipelinevariable und fügen Sie es zum Bereitstellungszeitpunkt mithilfe von envsubst oder sed in Kubernetes-Manifeste ein.

Definieren Sie eine Rollback-Strategie für Produktionsbereitstellungen, damit Sie sich schnell von einem fehlerhaften Release erholen können. Bei App Service bedeutet ein Rollback, den Produktionsslot wieder auf die vorherige Staging-Version zurückzusetzen. Verwenden Sie für AKS kubectl rollout undo. Erstellen Sie eine eigene Rollback-Pipeline oder fügen Sie einen manuellen Rollback-Job hinzu, der über das Azure-DevOps-Portal ausgelöst werden kann. Dokumentieren Sie das Rollback-Verfahren und üben Sie es regelmäßig — ein nicht getestetes Rollback ist kein Rollback.

Führen Sie nach jeder Produktionsbereitstellung automatisch eine Überprüfung der Überwachung aus, um zu bestätigen, dass die neue Version fehlerfrei ist. Verwenden Sie die AzureMonitor@1-Pipelineprüfung, um Azure-Monitor-Metriken abzufragen — sind die Fehlerraten nach der Bereitstellung erhöht, blockieren Sie den weiteren Verlauf der Pipeline und lösen Sie ein Rollback aus. Senden Sie Bereitstellungsbenachrichtigungen über Webhook-Tasks an Microsoft Teams oder Slack, damit das Team weiß, wann eine Bereitstellung abgeschlossen ist und welche Version aktiv ist.

Befolgen Sie diese Best Practices für Continuous Deployment: Stellen Sie häufig bereit (kleine Pakete reduzieren das Risiko), verwenden Sie Feature Flags, um Bereitstellung und Release zu entkoppeln, automatisieren Sie alle Qualitätsschranken vor der Produktion, nutzen Sie ein produktionsnahes Staging, damit Unterschiede keine Fehler verdecken, überwachen Sie Bereitstellungsfenster mit automatisierten Integritätsprüfungen und haben Sie immer einen getesteten Rollback-Plan. Eine ausgereifte CD-Pipeline macht die Bereitstellung zu einem unauffälligen Vorgang statt zu einem Ablauf unter hohem Stress.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: mehrstufige YAML-Pipelines verknüpfen die Phasen Build, Staging und Production und übergeben Artefakte, Bereitstellungsjobs mit Environments ermöglichen Genehmigungsschranken und die Nachverfolgung von Bereitstellungen, und Smoke-Tests nach der Staging-Bereitstellung verhindern, dass fehlerhafte Releases die Produktion erreichen. Als Nächstes sehen wir uns GitHub Actions in Azure an.