Handbuch

Sicherstellen der Codequalität (Build, Test, Abdeckung) vor dem Mergen eines Pull Requests.

→Konfigurieren Sie auf dem Zielbranch eine Build-Validierungsrichtlinie, die eine Pipeline bei der PR-Erstellung auslöst. Die Pipeline muss Codeabdeckungsergebnisse veröffentlichen. Legen Sie eine Branch-Richtlinie für die Mindestabdeckung fest.

Warum: Dies erzwingt Qualität vor dem Merge. Ein Standard-CI-Trigger läuft nach dem Merge. Release-Gates sind für Bereitstellungen, nicht für PRs.

Eine Git-Branching-Strategie auswählen, die Merge-Konflikte minimiert und schnelle, kontinuierliche Bereitstellung in die Produktion unterstützt.

→Implementieren Sie Trunk-Based Development mit kurzlebigen Feature-Branches, die häufig (täglich oder öfter) in `main` gemergt werden.

Warum: Verhindert, dass Branches erheblich auseinanderlaufen, reduziert Merge-Konflikte und stellt sicher, dass der `main`-Branch immer nahe an einem veröffentlichbaren Zustand ist.

Einen kritischen Branch (z.B. `main`) schützen, indem Code-Reviews, erfolgreiche Builds und die Verknüpfung von Arbeitselementen vor Merges erzwungen werden.

→Konfigurieren Sie Branch-Richtlinien für den `main`-Branch in Azure Repos. Aktivieren Sie Richtlinien für Mindestanzahl an Reviewern, Build-Validierung und Verknüpfung von Arbeitselementen.

Warum: Branch-Richtlinien bieten eine serverseitige Durchsetzung, die von Entwicklern nicht umgangen werden kann, und gewährleisten so konsistente Qualität und Prozesskonformität.

Eine Git-Branching-Strategie für ein Team mit geplanten Releases, paralleler Feature-Entwicklung und der Notwendigkeit dedizierter Hotfix-Branches auswählen.

→Implementieren Sie das GitFlow-Branching-Modell, das die Branches `main`, `develop`, `feature/*`, `release/*` und `hotfix/*` verwendet.

Warum: GitFlow bietet ein robustes Framework zur Verwaltung komplexer Release-Zyklen, das neue Entwicklungen von der Release-Stabilisierung und Notfall-Fixes isoliert.

Ein Geheimnis wurde versehentlich committed und gepusht. Es muss vollständig aus der gesamten Git-Historie entfernt werden.

→Zuerst das offengelegte Geheimnis rotieren. Verwenden Sie dann ein Tool wie `git-filter-repo` oder BFG Repo-Cleaner, um die Historie neu zu schreiben und die Datei zu entfernen. Pushen Sie die Änderungen zwangsweise und benachrichtigen Sie alle Entwickler, dass sie neu klonen müssen.

Warum: Ein einfaches `git rm` oder Revert entfernt das Geheimnis nicht aus der Historie. Eine Umschreibung der Historie ist für eine dauerhafte Bereinigung erforderlich.

Einen komplexen Workflow mit parallelen Stufen und Abhängigkeiten zwischen den Stufen modellieren.

→Verwenden Sie YAML-Multi-Stage-Pipelines. Nutzen Sie das `dependsOn`-Schlüsselwort für Stufenabhängigkeiten und konfigurieren Sie parallele Jobs innerhalb der Stufen.

Warum: YAML bietet den flexibelsten, codebasierten Ansatz für komplexe Orchestrierung, überlegen gegenüber klassischen Pipelines oder der Verknüpfung separater Pipelines.

Implementieren Sie eine Bereitstellung ohne Ausfallzeiten und mit geringem Risiko für eine Web-App mit sofortiger Rollback-Fähigkeit.

→Verwenden Sie Azure App Service Bereitstellungsslots. Stellen Sie in einem Staging-Slot (grün) bereit, validieren Sie und führen Sie dann einen Slot-Swap mit der Produktion (blau) durch.

Warum: Ein Slot-Swap ist ein atomarer, nahezu sofortiger Vorgang, der den Traffic umleitet. Ein Rollback ist so einfach wie das Zurückswappen.

Referenz↗

Minimieren Sie die Pipeline-Duplizierung für zahlreiche Microservices, die gemeinsame Build-/Bereitstellungsschritte verwenden, aber spezifische Anpassungen erfordern.

→Erstellen Sie YAML-Vorlagen in einem zentralen Repository. Verwenden Sie in jeder dienstspezifischen Pipeline das `extends`-Schlüsselwort und übergeben Sie Parameter zur Anpassung.

Warum: `extends` fördert DRY-Prinzipien und erzwingt Standards, während es Flexibilität durch Parameter ermöglicht. Leistungsfähiger als Aufgabengruppen für ganze Pipeline-Strukturen.

Beschränken Sie eine Pipeline-Phase (z.B. Produktionsbereitstellung) darauf, nur bei Merges in einen bestimmten Branch (z.B. main) ausgeführt zu werden.

→Verwenden Sie eine `condition` für die Phase oder den Job. Z.B., `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

Warum: PR-Validierungs-Builds verwenden eine andere Quellbranch-Referenz (z.B. `refs/pull/...`), daher verhindert diese Bedingung die Bereitstellung während des PR-Lebenszyklus korrekt.

Anwendungen von Azure DevOps auf lokale Server hinter einer Unternehmensfirewall bereitstellen.

→Installieren Sie selbstgehostete Agents auf den lokalen Servern. Registrieren Sie sie in einem Agent-Pool in Azure DevOps.

Warum: Selbstgehostete Agents initiieren ausgehende Kommunikation zu Azure DevOps, sodass keine eingehenden Firewall-Regeln erforderlich sind. Sie können auf lokale Netzwerkressourcen für die Bereitstellung zugreifen.

Mehrere Genehmigungen für Produktionsbereitstellungen anfordern und diese auf bestimmte Wartungsfenster beschränken.

→Definieren Sie eine Azure DevOps Umgebung für die Produktion. Konfigurieren Sie Genehmigungen mit erforderlichen Genehmigern. Fügen Sie eine "Geschäftszeiten"-Prüfung als Gate hinzu, um das Zeitfenster durchzusetzen.

Warum: Umgebungen zentralisieren die Bereitstellungssteuerungen. Genehmigungen und Gates bieten eine robuste, automatisierte Richtliniendurchsetzung, bevor eine Phase ausgeführt wird.

Die Freigabe von Features für Benutzer steuern, ohne die Anwendung neu bereitzustellen, mit nahezu Echtzeit-Updates.

→Verwenden Sie Azure App Configuration für das Feature-Management. Instrumentieren Sie die Anwendung, um Flags zu lesen und ihre dynamischen Aktualisierungsfunktionen zu aktivieren.

Warum: Entkoppelt Feature-Releases von Bereitstellungen. App Configuration bietet eine zentralisierte Benutzeroberfläche und SDKs für dynamische Updates, wodurch Anwendungsneustarts vermieden werden.

Den Kubernetes-Clusterzustand deklarativ verwalten, wobei Git die einzige Quelle der Wahrheit ist und Änderungen automatisch angewendet werden.

→Stellen Sie einen GitOps-Agenten wie Flux oder ArgoCD auf dem AKS-Cluster bereit. Konfigurieren Sie den Agenten so, dass er ein Git-Repository mit Kubernetes-Manifesten überwacht und den Clusterzustand automatisch synchronisiert.

Warum: Dieses Pull-basierte Modell ermöglicht kontinuierliche Abstimmung und Drift-Erkennung, was der Kern von GitOps ist. Es ist robuster als Push-basierte `kubectl`-Pipelines.

Terraform-Zustand für die Teamzusammenarbeit verwalten, um Sicherheit zu gewährleisten und gleichzeitige Änderungen zu verhindern.

→Konfigurieren Sie das Terraform-Backend zur Verwendung eines Azure Storage Accounts. Dies bietet eine Remote-Zustandsspeicherung, wobei die Zustandssperrung über Azure Blob Lease erfolgt.

Warum: Verhindert die Beschädigung von Zustandsdateien durch gleichzeitige `apply`-Operationen und hält sensible Zustandsdaten außerhalb der Quellcodeverwaltung.

Referenz↗

In einem Monorepo eine CI-Pipeline einer Anwendung nur dann auslösen, wenn Dateien in ihrem spezifischen Verzeichnis (oder einem gemeinsamen Verzeichnis) geändert werden.

→Verwenden Sie in der YAML-Datei der Pipeline den Filter `trigger.paths.include`, um die relevanten Verzeichnisse anzugeben, z.B. `include: ['/apps/frontend/**', '/apps/shared/**']`.

Warum: Dies vermeidet unnötige Builds bei nicht zusammenhängenden Codeänderungen und spart CI-Zeit und Rechenressourcen.

Eine Testphase mit schnellen (Unit-) und langsamen (Integrations-)Tests optimieren, um schnelleres Feedback zu erhalten.

→Führen Sie Unit-Tests und Integrationstests in parallelen Jobs innerhalb derselben Phase aus.

Warum: Die parallele Ausführung liefert Unit-Testergebnisse viel schneller, während langsamere Tests gleichzeitig ausgeführt werden. Die Gesamtdauer der Phase wird durch den längsten Job bestimmt, nicht durch die Summe.

Ein Bibliothekspaket automatisch basierend auf der Commit-Historie versionieren, um die Auswirkungen von Änderungen (Breaking Change, Feature, Fix) klar zu kommunizieren.

→Integrieren Sie ein Tool wie GitVersion in die CI-Pipeline. Es analysiert Commit-Nachrichten, Branches und Tags, um automatisch eine SemVer-Version (Major.Minor.Patch) zu berechnen.

Warum: SemVer bietet eine aussagekräftige Versionierung, auf die sich Konsumenten für das Abhängigkeitsmanagement verlassen können, im Gegensatz zu Build-Nummern oder Commit-Hashes.

Eine Anwendung nacheinander in mehreren geografischen Regionen bereitstellen, mit Validierung nach jeder regionalen Bereitstellung.

→Verwenden Sie eine YAML-Pipeline mit mehreren sequenziellen Phasen, eine für jede Region, wobei `dependsOn` die Reihenfolge erzwingt. Verwenden Sie Umgebungs-Gates zwischen den Phasen zur Validierung.

Warum: Dieses ringbasierte Bereitstellungsmodell begrenzt den Schadensbereich einer fehlerhaften Bereitstellung auf eine einzelne Region und ermöglicht ein Rollback, bevor alle Benutzer betroffen sind.

Eine Pipeline zur Unterstützung eines Trunk-Based Development-Modells konfigurieren, um sicherzustellen, dass der Main-Branch immer bereitstellbar ist.

→Konfigurieren Sie einen CI-Trigger auf dem `main`-Branch. Erzwingen Sie PRs mit einer Build-Validierungsrichtlinie, die schnelle, umfassende Tests ausführt. Integrieren Sie schnelle Benachrichtigungen (z.B. an Teams/Slack) bei Build-Fehlern.

Warum: Sofortiges Feedback ist beim Trunk-Based Development entscheidend. Diese Kombination verhindert das Mergen von fehlerhaftem Code und sorgt für schnelle Behebung von Problemen.

Große Artefakte (z.B. ML-Modelle, >5GB) effizient zwischen Pipeline-Phasen übergeben.

→Laden Sie das große Artefakt in der Produzentenphase in Azure Blob Storage hoch. Übergeben Sie den Blob-URI als Ausgabevariable an die Konsumentenphase.

Warum: Azure Blob Storage ist kostengünstiger und leistungsfähiger als eingebaute Pipeline-Artefakte für Multi-Gigabyte-Dateien.

Build-Zeiten reduzieren, indem das erneute Herunterladen von Abhängigkeiten (z.B. NuGet, npm) bei jedem Lauf vermieden wird.

→Verwenden Sie die Aufgabe `Cache@2`. Definieren Sie einen Schlüssel basierend auf der Paket-Lock-Datei (z.B. `packages.lock.json`). Die Aufgabe speichert und stellt den Abhängigkeitsordner wieder her.

Warum: Kann mehrere Minuten pro Build sparen, indem aus einem schnellen, lokalen Cache wiederhergestellt wird, anstatt von externen Repositories abzurufen.

Denselben Code parallel für mehrere Ziele (z.B. verschiedene Betriebssysteme, Regionen) bauen oder bereitstellen.

→Verwenden Sie eine `strategy: matrix` im YAML-Pipeline-Job. Definieren Sie Variablen für jede Kombination, die für jeden Matrixeintrag einen Job generieren.

Warum: Eine Matrix-Strategie hält die Pipeline-Definition DRY, erstellt mehrere Job-Variationen aus einer einzigen Definition und führt sie parallel aus.

Eine Canary-Bereitstellung auf AKS implementieren, die den Traffic automatisch verschiebt und basierend auf Echtzeit-Metriken hochstuft oder zurückrollt.

→Verwenden Sie einen Progressive-Delivery-Controller wie Flagger, integriert mit einem Service Mesh (z.B. Istio) und einem Metriken-Anbieter (z.B. Prometheus).

Warum: Flagger automatisiert den gesamten Canary-Analyseprozess und bietet eine sicherere und zuverlässigere progressive Bereitstellung als manuelle Skripte.

Eine Anwendungspipeline muss ausgelöst werden, wenn sich Code in ihrem eigenen Repository ODER in einem separaten, gemeinsam genutzten Bibliotheks-Repository ändert.

→Definieren Sie in der YAML-Datei der Anwendung die gemeinsam genutzte Bibliothek unter `resources.repositories` und konfigurieren Sie einen `trigger`-Block für diese Ressource.

Warum: Erstellt eine deklarative Abhängigkeit zwischen Repositories, wodurch sichergestellt wird, dass die Anwendung immer mit den neuesten freigegebenen Komponenten neu erstellt wird.

Eine Pipeline muss temporäre Infrastruktur für Tests erstellen und sicherstellen, dass diese danach wieder zerstört wird, auch wenn Tests fehlschlagen.

→Verwenden Sie eine Multi-Stage-Pipeline mit separaten Apply- und Destroy-Phasen für IaC (Terraform/Bicep). Konfigurieren Sie die Destroy-Phase mit `condition: always()`.

Warum: Die `always()`-Bedingung garantiert, dass die Bereinigungsphase unabhängig vom Erfolg oder Misserfolg früherer Phasen ausgeführt wird, wodurch verwaiste Ressourcen verhindert werden.

Eine Produktionsbereitstellung verhindern, es sei denn, es liegt eine genehmigte Änderungsanforderung in einem ITSM-Tool wie ServiceNow vor.

→Konfigurieren Sie ein Umgebungs-Gate, das das "Query ServiceNow"-Gate aufruft, um den Status der Änderungsanforderung zu überprüfen.

Warum: Automatisiert die Integration in Unternehmens-Change-Management-Prozesse, gewährleistet Compliance ohne manuelle Übergaben.

Einen Pool selbstgehosteter Build-Agents bereitstellen, der dynamisch mit der Nachfrage skaliert, um Warteschlangenzeiten zu reduzieren und Kosten zu kontrollieren.

→Konfigurieren Sie einen Azure DevOps Agent-Pool mit einer Azure Virtual Machine Scale Set (VMSS), die automatisch basierend auf der Anzahl der ausstehenden Jobs skaliert.

Warum: VMSS-Agents kombinieren die Anpassung selbstgehosteter Agents mit der Elastizität Cloud-gehosteter Agents, wodurch Leistung und Kosten optimiert werden.

Datenbankschemaänderungen so bereitstellen, dass Datenverlust verhindert und Rollbacks unterstützt werden.

→Verwenden Sie ein Migrationstool (z.B. Flyway, DbUp). Implementieren Sie das Expand/Contract-Muster für Schemaänderungen, um die Abwärtskompatibilität zu gewährleisten.

Warum: Migrationstools bieten Versionierung und Kontrolle. Das Expand/Contract-Muster entkoppelt Anwendungs- und Datenbank-Rollbacks und ermöglicht so sicherere Bereitstellungen.

Selbstgehostete Agents laufen aufgrund angesammelter Build-Artefakte der Festplattenspeicher aus.

→Konfigurieren Sie in der Pipeline-YAML-Datei auf Job-Ebene `workspace: clean: all`.

Warum: Diese präventive Pipeline-Konfiguration löst die Grundursache, ohne manuelles Eingreifen oder kontinuierliche Infrastrukturänderungen zu erfordern.

Integrationstests erfordern für jeden Pipeline-Lauf eine isolierte Datenbankinstanz.

→Definieren Sie eine Container-Ressource (z.B. SQL Server, Postgres) als Dienst in der Pipeline-YAML-Datei. Der Test-Job kann dann eine Verbindung zu diesem ephemeren Dienst herstellen.

Warum: Bietet schnelle, isolierte und automatisch bereinigte Abhängigkeiten für Tests, verhindert Testinterferenzen und vereinfacht die Einrichtung.

Zuverlässigkeit und Leistung der Paketwiederherstellung aus öffentlichen Repositories (z.B. npmjs, nuget.org) verbessern.

→Erstellen Sie in Azure Artifacts einen Feed und konfigurieren Sie Upstream-Quellen, die auf die öffentlichen Repositories verweisen. Lassen Sie Clients Pakete aus dem Azure Artifacts-Feed konsumieren.

Warum: Der Feed speichert Pakete aus Upstream-Quellen im Cache, schützt vor Ausfällen öffentlicher Repositories und beschleunigt die Wiederherstellung häufig verwendeter Pakete.

Ein Helm-Chart in mehreren Umgebungen (Dev, Prod) mit unterschiedlichen Konfigurationswerten bereitstellen.

→Verwenden Sie separate `values-<env>.yaml`-Dateien für jede Umgebung. Verwenden Sie in der `HelmDeploy`-Aufgabe den `valueFile`-Input, um die entsprechende Datei anzugeben, und `overrideValues`, um dynamische Werte wie Image-Tags einzufügen.

Warum: Dieses Muster trennt statische Umgebungskonfiguration von dynamischen Pipeline-Variablen und hält Bereitstellungen sauber und wartbar.

Geheimnisse (z.B. Verbindungszeichenfolgen) in Pipelines sicher verwalten und nutzen, ohne sie fest zu codieren.

→Speichern Sie Geheimnisse im Azure Key Vault. Erstellen Sie in Azure DevOps eine mit dem Key Vault verknüpfte Variablengruppe. Verweisen Sie in der Pipeline auf Geheimnisse aus der Variablengruppe.

Warum: Zentralisiert die Geheimnisverwaltung, ermöglicht die Rotation ohne Pipeline-Änderungen und bietet robuste Zugriffssteuerung und Überwachung durch Key Vault.

Sicherheitsscans in der CI-Pipeline implementieren, um Schwachstellen im Anwendungscode (SAST) und in Drittanbieter-Abhängigkeiten (SCA) zu erkennen.

→Integrieren Sie die Microsoft Security DevOps-Erweiterung, die mehrere Scanner enthält. Berücksichtigen Sie auch GitHub Advanced Security für Azure DevOps für eine native, umfassende Suite.

Warum: Dieser "Shift-Left"-Ansatz identifiziert Schwachstellen frühzeitig im Entwicklungslebenszyklus, wodurch Kosten und Risiken reduziert werden.

Den Entwicklerzugriff auf Produktionsumgebungen einschränken, um direkte Änderungen zu verhindern, während weiterhin überwachter Notfallzugriff möglich ist.

→Entfernen Sie dauerhafte Mitwirkender/Besitzer-Rollen. Verwenden Sie Pipeline-Service-Verbindungen für Bereitstellungen. Für Notfälle verwenden Sie Azure AD Privileged Identity Management (PIM) für Just-In-Time (JIT) erhöhte Zugriffsrechte.

Warum: PIM bietet zeitgebundenen, genehmigungsgesteuerten und vollständig überwachten erhöhten Zugriff, der dem Prinzip der geringsten Rechte folgt.

Geheimnisse sicher an Microservices in AKS bereitstellen, mit automatischer Rotation und workload-spezifischem Zugriff.

→Verwenden Sie Azure Key Vault in Verbindung mit dem Secrets Store CSI Driver für AKS. Verwenden Sie Workload Identity für Pods zur Authentifizierung am Key Vault.

Warum: Bindet Geheimnisse direkt aus dem Key Vault in Pods ein, wodurch Kubernetes Secrets vermieden werden. Ermöglicht Identität auf Pod-Ebene und nahtlose Geheimnisrotation.

Referenz↗

Erzwingen, dass nur gescannte und signierte Container-Images in einem Produktions-Kubernetes-Cluster bereitgestellt werden können.

→Verwenden Sie Azure Container Registry (ACR) Content Trust für die Image-Signierung. Verwenden Sie Microsoft Defender for Containers für das Scannen. Verwenden Sie Azure Policy für Kubernetes, um Richtlinien für AKS durchzusetzen.

Warum: Bietet eine umfassende, richtliniengesteuerte, mehrstufige Sicherheitsstrategie für Container-Images, vom Build bis zur Laufzeit.

Azure Pipelines mit Azure-Ressourcen verbinden, ohne Client-Geheimnisse oder Zertifikate zu verwenden.

→Erstellen Sie eine Azure Resource Manager-Dienstverbindung unter Verwendung von "Workload Identity Federation".

Warum: Eliminiert die Notwendigkeit, Geheimnisse zu verwalten und zu rotieren, und verbessert so die Sicherheit des CI/CD-Systems.

Bereitstellung in einem Azure-Abonnement eines Kunden von Ihrer Azure DevOps-Organisation aus, ohne Geheimnisse auszutauschen.

→Stellen Sie einen selbstgehosteten Agent in der Azure-Umgebung des Kunden bereit. Weisen Sie der VM/VMSS des Agents eine Managed Identity zu und gewähren Sie ihr die erforderlichen RBAC-Rollen.

Warum: Hält alle Authentifizierungsprinzipale innerhalb des Kunden-Tenants und folgt einem Zero-Trust-Modell. Keine Geheimnisse überqueren Tenant-Grenzen.

Die Arbeit mehrerer Teams an einem großen Produkt verwalten, Teamautonomie ermöglichen und gleichzeitig teamübergreifende Transparenz für die Führungskräfte schaffen.

→Verwenden Sie ein einziges Projekt mit Bereichspfaden für jedes Team, um ihnen gefilterte Backlogs zu geben. Verwenden Sie Lieferpläne, um Fortschritt und Abhängigkeiten teamübergreifend zu visualisieren.

Warum: Ermöglicht Rollup-Berichte und Abhängigkeitsverfolgung, während jedes Team seine eigenen Sprints und Arbeitselemente unabhängig verwalten kann.

Commits/PRs automatisch mit Arbeitselementen verknüpfen und den Zustand des Arbeitselements (z.B. auf "Gelöst") beim PR-Merge ändern.

→Aktivieren Sie in den Projekteinstellungen "Arbeitselemente automatisch mit Pull Requests abschließen". Entwickler müssen `#<ID>` in Commit-Nachrichten verwenden oder PRs verknüpfen.

Warum: Reduziert den manuellen Aufwand für Entwickler, hält den Status von Arbeitselementen aktuell und verbessert die Nachvollziehbarkeit zwischen Code und Anforderungen.

Wichtige Prozessmetriken wie Cycle Time, Lead Time und DORA-Metriken für die Wertstromanalyse messen.

→Verwenden Sie den Azure DevOps Analytics-Dienst und seinen OData-Feed. Verbinden Sie Power BI oder verwenden Sie integrierte Dashboard-Widgets, um diese Metriken zu visualisieren.

Warum: Der Analytics-Dienst liefert die zugrunde liegenden Daten für wichtige Flow- und SRE-Metriken und ermöglicht so eine datengesteuerte Prozessverbesserung.

Untersuchen Sie intermittierende langsame Antwortzeiten, die durch durchschnittliche Leistungsmetriken verdeckt werden.

→Verwenden Sie in Application Insights das Performance-Blatt mit Perzentil-Analyse (P95, P99) und Transaktionssuche, um spezifische langsame Anforderungsbeispiele zu untersuchen.

Warum: Durchschnitte können irreführend sein. Perzentile zeigen den "Long Tail" von Leistungsproblemen auf, die oft die am meisten frustrierten Benutzer betreffen.

Eine einzelne Benutzeranfrage verfolgen, während sie über mehrere Microservices hinwegläuft, um Engpässe oder Fehlerpunkte zu identifizieren.

→Instrumentieren Sie alle Dienste mit dem Application Insights SDK. Es propagiert automatisch eine W3C Trace Context Korrelations-ID über Dienstaufrufe hinweg.

Warum: Bietet eine einheitliche Ansicht einer verteilten Transaktion in der Anwendungszuordnung, wodurch komplexe Interaktionen debuggt werden können.

Das Service Level Objective (SLO) einer Anwendung proaktiv überwachen und *bevor* das SLO verletzt wird, benachrichtigt werden.

→Definieren Sie SLIs mithilfe von KQL-Abfragen in Azure Monitor. Erstellen Sie eine Alarmregel, die basierend auf der Fehlerbudget-Burn-Rate (wie schnell das Budget verbraucht wird) ausgelöst wird.

Warum: Burn-Rate-Alarme sind prädiktiv und geben Zeit zum Reagieren, bevor ein SLO verletzt wird und Benutzer erheblich betroffen sind.

Überprüfen, ob eine Bereitstellung aus Benutzersicht funktional erfolgreich war und nicht nur, dass die Pipeline-Aufgaben abgeschlossen wurden.

→Führen Sie als Nachbereitstellungsschritt oder Release-Gate Application Insights Verfügbarkeitstests (synthetisches Monitoring) aus, die wichtige Benutzerflüsse simulieren.

Warum: Ein Pipeline-Erfolg zeigt nur an, dass Daten verschoben wurden. Synthetische Tests bestätigen, dass die Anwendung tatsächlich funktioniert und fangen Fehlkonfigurationen oder Abhängigkeitsfehler ab.

Bereitstellungsereignisse visuell mit Änderungen der Anwendungsleistung und Fehlerratenmetriken korrelieren.

→Verwenden Sie die Azure Pipelines-Aufgabe, um "Release-Annotationen" in Application Insights zu erstellen, die einen Marker auf Metrikdiagrammen platzieren.

Warum: Bietet sofortiges visuelles Feedback, um schnell zu erkennen, ob eine kürzliche Bereitstellung eine Leistungsregression oder einen Fehler eingeführt hat.

Anwendungs- und Infrastrukturresilienz gegenüber Fehlern proaktiv und kontrolliert testen.

→Integrieren Sie Azure Chaos Studio in Release-Pipelines. Erstellen Sie Experimente, die Fehler (z.B. VM-Herunterfahren, Netzwerklatenz) injizieren und das Systemverhalten validieren.

Warum: Geht über das Testen auf erwartetes Verhalten hinaus, um unerwartete Fehler zu testen und Vertrauen in die Systemresilienz aufzubauen.