Freigeben über

CI/CD-Basisarchitektur mit Azure Pipelines

  • Artikel

Dieser Artikel beschreibt einen allgemeinen DevOps-Workflow für die Bereitstellung von Anwendungsänderungen in Staging- und Produktionsumgebungen in Azure. Die Lösung verwendet methoden für die kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD) mit Azure Pipelines.

Wichtig

In diesem Artikel wird eine allgemeine CI/CD-Architektur mit Azure Pipelines behandelt. Es ist nicht vorgesehen, die Besonderheiten der Bereitstellung in verschiedenen Umgebungen abzudecken, z. B. Azure App Services, virtuelle Computer und Azure Power Platform. Die spezifischen Einzelheiten zu den Bereitstellungsplattformen werden in separaten Artikeln behandelt.

Architektur

Architekturdiagramm einer CI/CD-Pipeline mit Azure Pipelines.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Anmerkung

Obwohl dieser Artikel CI/CD für Anwendungsänderungen behandelt, können Azure-Pipelines auch zum Erstellen von CI/CD-Pipelines für Änderungen an der Infrastruktur als Code (IaC) verwendet werden.

Datenfluss

Die Daten fließen wie folgt durch das Szenario:

  1. PR-Pipeline – Eine Pullanforderung (PR) an Azure Repos Git löst eine PR-Pipeline aus. Diese Pipeline führt schnelle Qualitätsprüfungen durch. Diese Prüfungen sollten Folgendes umfassen:

    • Bauen des Codes, das Abrufen von Abhängigkeiten aus einem Abhängigkeitsverwaltungssystem erfordert.
    • Die Verwendung von Tools zum Analysieren des Codes, z. B. statische Codeanalyse, Linting und Sicherheitsüberprüfung
    • Komponententests

    Wenn eine der Prüfungen fehlschlägt, endet die Pipelineausführung, und der Entwickler muss die erforderlichen Änderungen vornehmen. Wenn alle Überprüfungen erfolgreich sind, sollte die Pipeline einen PR-Review erfordern. Wenn die PR-Überprüfung 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 mit Azure Repos Git löst eine CI-Pipeline aus. Diese Pipeline führt dieselben Prüfungen wie die PR-Pipeline mit einigen wichtigen Ergänzungen aus. Die CI-Pipeline führt Integrationstests aus. Integrationstests können ressourcenintensiv sein, sodass die Ausführung in der CI-Pipeline die Entwicklungsgeschwindigkeit und die Fehlererkennung ausgleicht. Es ist auch wichtig zu wissen, dass das Bestehen von Tests in einem PR nicht immer sicherstellt, dass sie nach der Zusammenführung erfolgreich sind, da Änderungen im Main Branch neue Probleme verursachen können, was die Anforderungen an Tests nach der Zusammenführung unterstreicht. Diese Faktoren machen die CI-Pipeline zu einem besseren Ort für Integrationstests als die PR-Pipeline. Diese Integrationstests sollten die Bereitstellung der Lösung nicht erfordern, da die Build-Artefakte noch nicht erstellt wurden. Wenn die Integrationstests geheime Schlüssel erfordern, ruft die Pipeline diese geheimen Schlüssel aus Azure Key Vault ab. Wenn eine der Prü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 Pipeline Trigger – Das Veröffentlichen von Artefakten triggert die CD Pipeline.

  4. CD Veröffentlichung für Staging – Die CD-Pipeline lädt die Artefakte, die in der CI-Pipeline erstellt wurden, herunter und stellt die Lösung in einer Staging Umgebung 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. Wenn die Tests erfolgreich sind, kann eine manuelle Überprüfungsaufgabe implementiert werden, um eine Person oder Gruppe zu veranlassen, die Bereitstellung zu validieren und die Pipeline fortzusetzen.

  5. CD Veröffentlichung für Produktion – Wenn der manuelle Eingriff wieder aufgenommen 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 manueller Eingriffsschritt zu einem Abbruch führt, das Release fehlschlägt oder die Rauchtests fehlschlagen, wird das Release zurückgesetzt, die Pipeline endet und der Entwickler muss die erforderlichen Änderungen vornehmen.

  6. Monitoring – Azure Monitor sammelt Beobachtbarkeitsdaten wie Protokolle und Metriken, sodass ein Bediener 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 dient als Code-Repository, das Versionssteuerung und eine Plattform für gemeinsame Projekte bereitstellt.

  • Azure Pipelines bietet eine Möglichkeit zum Erstellen, Testen, Verpacken und Freigeben von Anwendungs- und Infrastrukturcode. In diesem Beispiel gibt es drei unterschiedliche Pipelines mit den folgenden Zuständigkeiten:

    • PR Pipelines validieren den Code, bevor sie die Möglichkeit bieten, einen PR durch Linting, Build und Unit-Tests zusammenzuführen.
    • CI-Pipelines werden nach dem Zusammenführen von Code ausgeführt. Sie führen dieselbe Validierung wie PR-Pipelines durch, fügen jedoch Integrationstests hinzu und veröffentlichen Build-Artefakte, falls alles erfolgreich verläuft.
    • CD-Pipelines stellen Buildartefakte bereit und führen Akzeptanztests sowie die Veröffentlichung in der Produktionsumgebung durch.

  • Azure Artifact Feeds ermöglichen Ihnen das Verwalten und Freigeben von Softwarepaketen wie Maven, npm und NuGet. Artifakt-Feeds ermöglichen es Ihnen, den Lebenszyklus Ihrer Pakete zu verwalten, einschließlich der Versionsverwaltung, Bewerbung und Außerdienststellung von Paketen. Dadurch können Sie sicherstellen, dass Ihr Team die neuesten und sichersten Versionen Ihrer Pakete verwendet.

  • Key Vault- bietet eine Möglichkeit, sichere Daten für Ihre Lösung zu verwalten, einschließlich geheimer Schlüssel, Verschlüsselungsschlüssel und Zertifikate. In dieser Architektur wird es verwendet, um geheime Anwendungsschlüssel zu speichern. Auf diese geheimen Schlüssel 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.

  • Überwachen ist eine Observability-Ressource, die Metriken und Protokolle, Anwendungstelemetrie und Plattformmetriken für die Azure-Dienste sammelt und speichert. Verwenden Sie diese Daten, um die Anwendung zu überwachen, Warnungen, Dashboards einzurichten und Ursachenanalysen von Fehlern durchzuführen.

  • Application Insights ist ein Überwachungsdienst, der Echtzeit-Einblicke in die Leistung und Nutzung Ihrer Webanwendungen bietet.

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

Alternativen

Während sich dieser Artikel auf Azure-Pipelines konzentriert, können Sie diese Alternativen in Betracht ziehen:

  • Azure DevOps Server- kann als lokaler Ersatz verwendet werden.

  • Jenkins ist ein Open Source-Tool zum Automatisieren von Builds und Bereitstellungen.

  • GitHub-Aktionen ermöglichen Es Ihnen, Ihre CI/CD-Workflows direkt über GitHub zu automatisieren.

  • GitHub-Repositories können als Code-Repository ersetzt werden. Azure-Pipelines werden nahtlos in GitHub-Repositorys integriert.

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

  • App Service 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 problemlos in Windows- und Linux-basierten Umgebungen ausführen und skalieren. 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 verarbeitet Workloads, die ein hohes Maß an Kontrolle erfordern, oder von Betriebssystemkomponenten und Diensten abhängen, die mit Web-Apps nicht möglich sind.

  • Azure Power Platform ist eine Sammlung von Clouddiensten, mit denen Benutzer Anwendungen erstellen, bereitstellen und verwalten können, ohne dass infrastruktur- oder technische Kenntnisse erforderlich sind.

  • Azure Functions ist eine serverlose Computeplattform, mit der Sie Anwendungen erstellen können. Mit Funktionen können Sie Trigger und Bindungen verwenden, um Dienste zu 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-Container-Orchestrierungsplattform.

  • Azure Container Apps ermöglicht es Ihnen, containerisierte Anwendungen auf einer serverlosen Plattform auszuführen.

Szenariodetails

Die Verwendung bewährter CI- und CD-Methoden zum Bereitstellen von Anwendungs- oder Infrastrukturänderungen bietet verschiedene Vorteile:

  • Kürzere Veröffentlichungszyklen – Automatisierte CI/CD-Prozesse lassen eine schnellere Bereitstellung zu als manuelle Verfahren. Viele Unternehmen führen die Bereitstellung mehrmals am Tag durch.
  • Bessere Codequalität – Qualitätsprüfungen in CI-Pipelines, wie Linting und Unit-Tests, führen zu qualitativ hochwertigerem Code.
  • Reduziertes Risiko bei der Veröffentlichung – Richtige CI/CD-Verfahren verringern das Risiko bei der Veröffentlichung neuer Funktionen drastisch. Die Bereitstellung kann vor der Veröffentlichung getestet werden.
  • Höhere Produktivität – Automatisierte CI/CD befreit Entwickler von der Arbeit an manuellen Integrationen und Bereitstellungen, damit sie sich auf neue Features konzentrieren können.
  • Rollbacks ermöglichen – Auch wenn durch richtige CI/CD-Praktiken die Zahl der Fehler oder Regressionen, die veröffentlicht werden, sinkt, treten sie immer noch auf. CI/CD kann automatisierte Rollbacks auf frühere Versionen aktivieren.

Potenzielle Anwendungsfälle

Berücksichtigen Sie Azure Pipelines und CI/CD-Prozesse für:

  • Beschleunigen von Anwendungsentwicklungs- und Bereitstellungszyklen.
  • Einbindung von Qualität und Konsistenz in einen automatisierten Build- und Release-Prozess.
  • Erhöhung der Anwendungsstabilität und Betriebszeit.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, das eine Reihe von leitden Tenets ist, die verwendet werden können, um die Qualität einer Workload zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Operative Exzellenz

  • 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. Im Kontext wird häufig auf einen Prozess verwiesen, wobei vertrauliche Informationen (z. B. API-Schlüssel, Kennwörter oder andere geheime Schlüssel) während der Bereitstellung oder Konfiguration durch Token oder Platzhalter ersetzt werden.

  • Verwenden Sie Releasevariablen in Ihren Releasedefinitionen, um Konfigurationsänderungen Ihrer Umgebungen zu fördern. Releasevariablen können auf eine gesamte Version oder eine bestimmte Umgebung angewendet werden. Wenn Sie Variablen für geheime Informationen verwenden, stellen Sie sicher, dass Sie das Vorhängeschlosssymbol auswählen.

  • 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 von hohen Buildvolumes können selbst gehostete Agents verwendet werden, um Builds auf kosteneffiziente Weise zu beschleunigen.

  • Erwägen Sie, Application Insights und andere Überwachungstools so früh wie möglich in Ihrer Releasepipeline zu verwenden. Viele Organisationen beginnen nur mit der Überwachung in ihrer Produktionsumgebung. Durch die Überwachung Ihrer anderen Umgebungen können Sie Fehler früher im Entwicklungsprozess identifizieren und Probleme in Ihrer Produktionsumgebung vermeiden.

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

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

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

  • Erwägen Sie das Erstellen von Umgebungen über Staging und Produktion hinaus, um Aktivitäten wie manuelle Benutzerakzeptanztests, Leistung und Auslastungstests und Rollbacks zu unterstützen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Kostenoptimierungssäule.

Die Kosten für Azure DevOps hängen von der Anzahl der Benutzer in Ihrer Organisation ab, die Zugriff erfordern, sowie von anderen Faktoren wie der Anzahl der erforderlichen Build-/Freigaben und der Anzahl der Testbenutzer. Weitere Informationen finden Sie unter Azure DevOps-Preis.

Dieser Preisrechner bietet eine Schätzung für die Ausführung von Azure DevOps mit 20 Benutzern.

Azure DevOps wird pro Benutzer pro Monat abgerechnet. Abhängig von den benötigten parallelen Pipelines können weitere Belastungen anfallen, zusätzlich zu weiteren Testbenutzern oder Benutzer-Basislizenzen.

Sicherheit

  • Berücksichtigen Sie die Sicherheitsvorteile der Verwendung von von Microsoft gehosteten Agents bei der Auswahl, ob microsoft-gehostete oder selbst gehostete Agents verwendet werden sollen.

  • Stellen Sie sicher, dass alle Änderungen an Umgebungen über Pipelines erfolgen. Implementieren Sie rollenbasierte Zugriffssteuerungen (RBAC) nach dem Prinzip der geringsten Rechte, um Benutzer an dem Zugang zu Umgebungen zu hindern.

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

Nächste Schritte

Lesen Sie die folgenden Ressourcen, um mehr über CI/CD und Azure DevOps zu erfahren: