CI/CD-Baselinearchitektur mit Azure Pipelines

  • Artikel

In diesem Artikel wird ein allgemeiner DevOps-Workflow für die Bereitstellung von Anwendungsänderungen in Staging- und Produktionsumgebungen in Azure beschrieben. Die Lösung verwendet CI/CD-Verfahren (Continuous Integration und Continuous Delivery) mit Azure Pipelines.

Wichtig

In diesem Artikel wird eine allgemeine CI/CD-Architektur behandelt, die Azure Pipelines verwendet. Es ist nicht vorgesehen, die Besonderheiten der Bereitstellung in verschiedenen Umgebungen wie Azure App Services, Virtual Machines und Azure Power Platform zu behandeln. Besonderheiten von Bereitstellungsplattformen werden in separaten Artikeln behandelt.

Aufbau

Architekturdiagramm einer CI/CD-Pipeline, die Azure Pipelines verwendet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Hinweis

Obwohl dieser Artikel CI/CD für Anwendungsänderungen behandelt, können Sie Azure Pipelines auch verwenden, um CI/CD-Pipelines für IaC-Änderungen (Infrastructure-as-Code) zu erstellen.

Datenfluss

Die Daten durchlaufen das Szenario wie folgt:

  1. PR-Pipeline: Ein Pull Request (PR) an Azure Repos-Git löst eine PR-Pipeline aus. Diese Pipeline führt schnelle Qualitätsprüfungen durch. Diese Überprüfungen sollten Folgendes umfassen:

    • Erstellen des Codes, was das Pullen von Abhängigkeiten aus einem Abhängigkeitsverwaltungssystem erfordert.
    • Die Verwendung von Tools zur Analyse des Codes, z. B. statische Codeanalyse, Linting und Sicherheitsüberprüfung
    • Komponententests

    Wenn eine der Überprüfungen fehlschlägt, wird die Pipelineausführung beendet, und der Entwickler muss die erforderlichen Änderungen vornehmen. Wenn alle Überprüfungen erfolgreich sind, sollte die Pipeline einen PR-Review erfordern. Wenn der PR-Review fehlschlägt, endet die Pipeline, und der Entwickler muss die erforderlichen Änderungen vornehmen. Wenn alle Überprüfungen und PR-Review erfolgreich sind, wird der PR erfolgreich zusammengeführt.

  2. CI-Pipeline: Eine Zusammenführung in Azure Repos-Git löst eine CI-Pipeline aus. Diese Pipeline führt die gleichen Überprüfungen wie die PR-Pipeline aus, allerdings mit einigen wichtigen Ergänzungen. Die CI-Pipeline führt Integrationstests durch. Für diese Integrationstests sollte die Bereitstellung der Lösung nicht erforderlich sein, da die Buildartefakte noch nicht erstellt wurden. Wenn die Integrationstests Geheimnisse erfordern, ruft die Pipeline diese Geheimnisse aus Azure Key Vault ab. Wenn eine der Überprüfungen fehlschlägt, endet die Pipeline, und der Entwickler muss die erforderlichen Änderungen vornehmen. Das Ergebnis einer erfolgreichen Ausführung dieser Pipeline ist die Erstellung und Veröffentlichung von Buildartefakten.

  3. CD-Pipelinetrigger: Die Veröffentlichung von Artefakten löst die CD-Pipeline aus.

  4. CD-Release für Staging: Die CD-Pipeline lädt die in der CI-Pipeline erstellten Buildartefakte herunter und stellt die Lösung in einer Stagingumgebung bereit. Anschließend führt die Pipeline Akzeptanztests für die Stagingumgebung durch, um die Bereitstellung zu überprüfen. Wenn ein Akzeptanztest fehlschlägt, endet die Pipeline, und der Entwickler muss die erforderlichen Änderungen vornehmen. Sind die Tests erfolgreich, kann eine manuelle Überprüfungsaufgabe implementiert werden, mit der eine Überprüfung der Bereitstellung durch eine Person oder Gruppe erforderlich gemacht wird, die die Pipeline dann auch fortsetzt.

  5. CD-Release für Produktion: Wenn der manuelle Eingriff fortgesetzt wird oder kein manueller Eingriff implementiert ist, gibt die Pipeline die Lösung für die Produktion frei. Die Pipeline sollte Buildüberprüfungstests in der Produktion ausführen, um sicherzustellen, dass das Release wie erwartet funktioniert. Wenn ein Schritt des manuellen Eingriffs zu einem Abbruch führt, das Release fehlschlägt oder die Buildüberprüfungstests fehlschlagen, wird ein Rollback des Release ausgeführt, die Pipeline endet, und der Entwickler muss die erforderlichen Änderungen vornehmen.

  6. Überwachung: Azure Monitor sammelt Beobachtungsdaten wie Protokolle und Metriken, sodass ein Operator Integritäts-, Leistungs- und Nutzungsdaten analysieren kann. Application Insights sammelt alle anwendungsspezifischen Überwachungsdaten, z. B. Ablaufverfolgungen. Azure Log Analytics wird verwendet, um alle diese Daten zu speichern.

Komponenten

  • Ein Azure Repos-Git-Repository fungiert als Coderepository, das Versionskontrolle und eine Plattform für Zusammenarbeitsprojekte bereitstellt.

  • Azure Pipelines kann zum Erstellen, Testen, Packen und Freigeben von Anwendungs- und Infrastrukturcode verwendet werden. Dieses Beispiel umfasst drei unterschiedliche Pipelines mit folgenden Zuständigkeiten:

    • PR-Pipelines überprüfen Code durch Linten, Erstellung und Komponententests, bevor die Zusammenführung eines PR zugelassen wird.
    • CI-Pipelines werden nach dem Zusammenführen von Code ausgeführt. Sie führen die gleiche Überprüfung durch wie PR-Pipelines, ergänzen diese aber noch durch Integrationstests und veröffentlichen Buildartefakte, wenn alles erfolgreich war.
    • CD-Pipelines stellen Buildartefakte bereit und führen Akzeptanztests sowie die Veröffentlichung in der Produktionsumgebung durch.

  • Mit Azure-Artefaktfeeds können Sie Softwarepakete wie Maven, npm und NuGet verwalten und freigeben. Artefaktfeeds ermöglichen es Ihnen, den Lebenszyklus Ihrer Pakete zu verwalten, einschließlich Versionsverwaltung, Höherstufen und Einstellen von Paketen. Dadurch können Sie sicherstellen, dass Ihr Team die neuesten und sichersten Versionen Ihrer Pakete verwendet.

  • Key Vault dient zur Verwaltung sicherer Daten für Ihre Lösung, einschließlich Geheimnissen, Verschlüsselungsschlüsseln und Zertifikaten. In dieser Architektur wird Azure Key Vault zum Speichern von Anwendungsgeheimnissen verwendet. Auf diese Geheimnisse wird über die Pipeline zugegriffen. Azure Pipelines kann auf Geheimnisse mit einer Key Vault-Aufgabe oder durch Verknüpfen von Geheimnissen aus Key Vault zugreifen.

  • Ein Monitor ist eine Beobachtbarkeitsressource, die Metriken und Protokolle, Anwendungstelemetrie und Plattformmetriken zu Azure-Diensten sammelt und speichert. Nutzen Sie diese Daten zum Überwachen der Anwendung, Einrichten von Warnungen und Dashboards und Durchführen von Analysen der Grundursache von Fehlern.

  • Application Insights ist ein Überwachungsdienst, der Echtzeiterkenntnisse über die Leistung und Nutzung Ihrer Webanwendungen bietet.

  • Der Log Analytics-Arbeitsbereich bietet einen zentralen Speicherort, an dem Sie Daten aus mehreren Quellen speichern, abfragen und analysieren können, einschließlich Azure-Ressourcen, -Anwendungen und -Diensten.

Alternativen

In diesem Artikel steht Azure Pipelines im Mittelpunkt. Es gibt aber auch noch folgende Alternativen:

  • Azure DevOps Server (vormals Team Foundation Server) kann als lokale Alternative genutzt werden.

  • Jenkins ist ein Open-Source-Tool zum Automatisieren von Buildvorgängen und Bereitstellungen.

  • GitHub Actions ermöglicht das direkte Automatisieren Ihrer CI/CD-Workflows über GitHub.

  • GitHub-Repositorys können das Coderepository ersetzen. Azure Pipelines lässt sich nahtlos in GitHub-Repositorys integrieren.

Dieser Artikel konzentriert sich auf allgemeine CI/CD-Methoden mit Azure Pipelines. Im Folgenden sind einige Computeumgebungen aufgeführt, in denen Sie die Bereitstellung in Betracht ziehen könnten:

  • App Services ist ein HTTP-basierter Dienst zum Hosten von Webanwendungen, REST-APIs und mobilen Back-Ends. Sie können in Ihrer bevorzugten Sprache entwickeln und Anwendungen ausführen und skalieren, um sowohl Windows- als auch Linux-basierte Umgebungen zu vereinfachen. Web-Apps unterstützt Bereitstellungsslots wie Staging und Produktion. Sie können eine Anwendung in einem Stagingslot bereitstellen und in einem Produktionsslot freigeben.

  • Azure Virtual Machines: Kann für Workloads verwendet werden, die ein hohes Maß an Kontrolle erfordern oder von Betriebssystemkomponenten und -diensten abhängig sind, die mit Web-Apps nicht genutzt werden können (etwa der globale Assemblycache von Windows oder COM).

  • Azure Power Platform ist eine Sammlung von Clouddiensten, mit denen Benutzer Anwendungen ohne Infrastruktur oder technisches Fachwissen erstellen, bereitstellen und verwalten können.

  • Azure Functions ist eine serverlose Computeplattform, auf der Sie Anwendungen erstellen können. Bei Functions können Sie Dienste mithilfe von Triggern und Datenbindungen im gewünschten Umfang integrieren. Functions unterstützt zudem Bereitstellungsslots wie Staging und Produktion. Sie können eine Anwendung in einem Stagingslot bereitstellen und in einem Produktionsslot freigeben.

  • Azure Kubernetes Service (AKS) ist ein verwalteter Kubernetes-Cluster in Azure. Kubernetes ist eine Open-Source-Plattform für die Containerorchestrierung.

  • Azure Container Apps ermöglicht das Ausführen containerisierter Anwendungen auf einer serverlosen Plattform.

Szenariodetails

Die Verwendung bewährter CI/CD-Methoden zur Bereitstellung von Änderungen an Anwendungen oder Infrastrukturen bietet mehrere Vorteile:

  • Kürzere Releasezyklen – Automatisierte CI/CD-Prozesse ermöglichen Ihnen eine schnellere Bereitstellung als manuelle Verfahren. Viele Unternehmen führen die Bereitstellung mehrmals am Tag durch.
  • Bessere Codequalität – Quality Gates in CI-Pipelines, z. B. das Linten und Komponententests, führen zu einer höheren Codequalität.
  • Vermindertes Risiko der Veröffentlichung – Geeignete CI/CD-Verfahren verringern das Risiko der Veröffentlichung neuer Features drastisch. Die Bereitstellung kann vor der Veröffentlichung getestet werden.
  • Erhöhte Produktivität – Automatisiertes CI/CD befreit die Entwickler von der Arbeit an manuellen Integrationen und Bereitstellungen, sodass sie sich auf neue Features konzentrieren können.
  • Aktivieren von Rollbacks – Obwohl geeignete CI/CD-Methoden die Anzahl der veröffentlichten Fehler oder Regressionen verringern, treten sie dennoch weiterhin auf. CI/CD kann automatisierte Rollbacks für frühere Releases ermöglichen.

Mögliche Anwendungsfälle

Azure Pipelines und CI/CD-Prozesse eignen sich für Folgendes:

  • Beschleunigen der Anwendungsentwicklung und Entwicklungslebenszyklen.
  • Sicherstellen der Qualität und Konsistenz für den automatisierten Build- und Freigabeprozess.
  • Steigern von Anwendungsstabilität und -betriebszeit.

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das eine Reihe von Leitprinzipien enthält, die zur Verbesserung der Qualität eines Workloads verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Erstklassige Betriebsprozesse

  • Erwägen Sie die Implementierung von Infrastructure-as-Code (IaC), um Ihre Infrastruktur zu definieren und sie in Ihren Pipelines bereitzustellen.

  • Erwägen Sie die Verwendung einer der Tokenisierungsaufgaben , die im VSTS-Marketplace verfügbar sind. Beziehen Sie sich im Kontext häufig auf einen Prozess, bei dem vertrauliche Informationen (z. B. API-Schlüssel, Kennwörter oder andere Geheimnisse) während der Bereitstellung oder Konfiguration durch Token oder Platzhalter ersetzt werden.

  • Verwenden Sie Releasevariablen in Ihren Releasedefinitionen, um Konfigurationsänderungen Ihrer Umgebungen zu steuern. Releasevariablen können für eine gesamte Freigabe oder eine bestimmte Umgebung gelten. Denken Sie daran, auf das Schlosssymbol zu klicken, wenn Sie Variablen für Geheimnisinformationen verwenden.

  • Erwägen Sie bei Bereitstellungen für Ressourcen, die in einem geschützten virtuellen Netzwerk ausgeführt werden, die Verwendung selbstgehosteter Agents. Sie können auch selbstgehostete Agents in Betracht ziehen, wenn Sie eine große Anzahl von Builds ausführen. In Fällen mit hohen Buildvolumes können selbstgehostete Agents verwendet werden, um Builds kosteneffizient zu beschleunigen.

  • Erwägen Sie die Verwendung von Application Insights und anderen Überwachungstools so früh wie möglich in der Releasepipeline. Viele Organisationen beginnen erst in der Produktionsumgebung mit der Überwachung. Durch die Überwachung Ihrer anderen Umgebungen lassen sich Fehler früher im Entwicklungsprozess erkennen und Probleme in der Produktionsumgebung vermeiden.

  • Erwägen Sie die Verwendung separater Überwachungsressourcen für die Produktion.

  • Erwägen Sie die Verwendung von YAML-Pipelines anstelle der klassischen Schnittstelle. YAML-Pipelines können wie andere Code behandelt werden. YAML-Pipelines können beispielsweise in die Quellcodeverwaltung eingecheckt und versioniert werden.

  • Erwägen Sie die Verwendung von YAML-Vorlagen, um Wiederverwendung zu fördern und Pipelines zu vereinfachen. PR- und CI-Pipelines sind sich beispielsweise ähnlich. Eine einzelne parametrisierte Vorlage kann für beide Pipelines verwendet werden.

  • Erwägen Sie die Erstellung von Umgebungen, die über Staging und Produktion hinausgehen, um Aktivitäten wie manuelle Benutzerakzeptanztests, Leistungs- und Auslastungstests sowie Rollbacks zu unterstützen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kosten für Azure DevOps richten sich nach der Anzahl von Benutzern in Ihrer Organisation, die Zugriff benötigen, und anderen Faktoren wie der Anzahl von erforderlichen gleichzeitigen Builds/Releases sowie der Anzahl von Testbenutzern. Weitere Informationen finden Sie in der Azure DevOps-Preisübersicht.

Der Preisrechner liefert eine Kostenschätzung für den Betrieb von Azure DevOps mit 20 Benutzern.

Azure DevOps wird monatlich nach Benutzern abgerechnet. Unter Umständen fallen weitere Gebühren an, die sich nach den benötigten gleichzeitigen Pipelines und den zusätzlichen Testbenutzern bzw. Basic-Lizenzen für Benutzer richten.

Sicherheit

  • Berücksichtigen Sie die Sicherheitsvorteile der Verwendung von von Microsoft gehosteten Agents, wenn Sie entscheiden, ob von Microsoft gehostete oder selbstgehostete Agents verwendet werden sollen.

  • Stellen Sie sicher, dass alle Änderungen an Umgebungen über Pipelines erfolgen. Implementieren Sie rollenbasierte Zugriffssteuerungen (Role-Based Access Controls, RBAC) gemäß dem Prinzip der geringsten Rechte, wodurch Benutzer am Zugriff auf Umgebungen gehindert werden.

  • Erwägen Sie die Integration von Schritten in Azure Pipelines, um Abhängigkeiten nachzuverfolgen, die Lizenzierung zu verwalten, nach Sicherheitsrisiken zu suchen und Abhängigkeiten auf dem neuesten Stand zu halten.

Nächste Schritte

Die folgenden Ressourcen enthalten weitere Informationen zu CI/CD und Azure DevOps: