Planen einer Releasepipeline mithilfe von Azure Pipelines
In diesem Abschnitt begleiten Sie Andy und Mara bei der Planung einer grundlegenden CD-Pipeline, die in Azure Pipelines ausgeführt wird.
Wenn dies erledigt ist, wird sie dem Rest des Teams vorgeführt. Die Pipeline dient als POC, den sie mit zunehmenden Kenntnissen und Feedback von Tim und Amita verbessern und erweitern werden.
Was sind die Bestandteile einer grundlegenden CD-Pipeline?
Eine grundlegende CD-Pipeline enthält einen Trigger, um den Prozess in Gang zu setzen, und mindestens eine Phase (Stage) oder Bereitstellungsphase. Eine Phase besteht aus Aufträgen. Ein Auftrag ist eine Abfolge von Schritten, die definiert, wie Ihre Anwendung erstellt, getestet oder bereitgestellt werden soll.
Andy: Wir verfügen bereits über das Buildartefakt 
. Es ist die ZIP-Datei, die unsere bestehende Buildpipeline erstellt. Aber wie stellen wir es in einer Liveumgebung 
bereit?
Was ist eine Pipelinephase?
Eine Phase (Stage) ist ein Teil der Pipeline, der unabhängig ausgeführt und von verschiedene Mechanismen ausgelöst werden kann. Ein Mechanismus kann der Erfolg der vorherigen Phase, ein Zeitplan oder sogar ein manueller Trigger sein. Über diese Mechanismen erfahren Sie mehr im nächsten Modul.
Mara: Wir könnten in einer Phase die App erstellen und in einer anderen die Tests durchführen.
Mara: Wir haben die Aufgaben für die Buildphase bereits in unserer Pipeline definiert. Unsere Bereitstellungsphase kann ähnlich aussehen und Aufgaben beinhalten, die den Build in einer Umgebung bereitstellen.
Die Frage ist, wo sollen wir das Artefakt bereitstellen?
Was ist eine Umgebung?
Wahrscheinlich haben Sie den Begriff Umgebung schon verwendet, um den Ort zu bezeichnen, an dem Ihre Anwendung oder Ihr Dienst ausgeführt wird. Zum Beispiel könnte Ihre Produktionsumgebung der Ort sein, an dem Ihre Endbenutzer*innen auf Ihre Anwendung zugreifen.
Diesem Beispiel folgend, könnte Ihre Produktionsumgebung Folgendes sein:
- Ein physischer Computer oder ein virtueller Computer (VM).
- Eine containerisierte Umgebung, z. B. Kubernetes.
- Ein verwalteter Dienst, z. B. Azure App Service.
- Eine serverlose Umgebung, z. B. Azure Functions.
Ein Artefakt wird in einer Umgebung bereitgestellt. Azure Pipelines erleichtert die Bereitstellung in nahezu jeder Art von Umgebung, ob lokal oder in der Cloud.
In Azure Pipelines hat der Begriff Umgebung eine zweite Bedeutung. Hier handelt es sich bei einer Umgebung um eine abstrakte Darstellung Ihrer Bereitstellungsumgebung, z. B. einen Kubernetes-Cluster, eine App Service-Instanz oder einen virtuellen Computer.
Eine Azure Pipelines-Umgebung zeichnet den Bereitstellungsverlauf auf, damit Sie die Quelle von Änderungen besser identifizieren können. Durch die Verwendung von Azure Pipelines-Umgebungen können Sie auch Sicherheitsüberprüfungen definieren sowie Möglichkeiten zur Steuerung, wie ein Artefakt von einer Phase einer Pipeline zur nächsten höhergestuft wird. Was eine Umgebung umfasst, hängt davon ab, was Sie mit dem Artefakt machen wollen. Eine Umgebung, in der Sie das Artefakt testen möchten, wird wahrscheinlich anders definiert sein als eine, in der Sie das Artefakt für Ihre Endbenutzer bereitstellen möchten.
Eine Möglichkeit zum Definieren einer Azure Pipelines-Umgebung ist mit einer YAML-Datei. Ihre YAML-Datei enthält einen environment-Abschnitt, mit dem die Azure Pipelines-Umgebung angegeben wird, in der Sie Ihr Artefakt bereitstellen wollen.
Während Sie Ihre Releasepipeline planen, müssen Sie entscheiden, wo Ihre Anwendung oder Ihr Dienst ausgeführt werden soll. Lassen Sie uns reinhören und sehen, was Andy und Mara entscheiden.
Andy: Mal allgemein gesprochen, was für eine Art von Umgebung wollen wir eigentlich? Wollen wir lokal oder in der Cloud bereitstellen?
Mara: Wir könnten Tim bitten, eine VM für uns im Lab zu erstellen, aber ihm geht ständig die Hardware aus. Wenn wir die Cloud verwenden, können wir selber ganz schnell und einfach einen POC einrichten.
Andy: Ich stimme zu, aber es gibt so viele Cloudoptionen, die wir in Betracht ziehen können, und wir können Azure Pipelines verwenden, um in jeder davon bereitzustellen. Welche sollen wir ausprobieren?
Mara: Die Teams, die unsere Spiele entwickeln, benutzen Azure, um einige ihrer Back-End-Systeme zu hosten. Das Einrichten geht schnell, und es scheint ihnen zu gefallen. Ich denke, wir sollten bei Azure für unsere Cloud bleiben.
Andy: Ok, das klingt gut! Aber Azure bietet so viele Compute-Optionen. Welche sollen wir nehmen?
Andy listet diese Optionen auf dem Whiteboard auf:
- Virtuelle Computer
- Container
- Azure App Service
- Serverloses Computing
Hinweis
Weitere Informationen zu jeder dieser Compute-Optionen finden Sie am Ende dieses Moduls.
Mara: Ich weiß, dass Container und serverloses Computing gerade sehr beliebt sind. Im Vergleich zu VMs sind beide recht schlank, was die Ressourcen angeht. Außerdem sind sie leicht zu ersetzen und horizontal zu skalieren. Beides ist interessant, aber es macht mich etwas nervös, zwei neue Technologien gleichzeitig lernen zu müssen. Ich würde mich lieber nur auf den Aufbau der Pipeline konzentrieren.
Andy: Da bin ich ganz bei dir. Bleiben also VMs oder App Service. Ich denke, VMs wären die bessere Wahl, wenn wir eine branchenspezifische App in die Cloud bringen würden, also eine, die vollen Zugriff auf eine bestimmte Umgebung benötigt. Aber wir machen nichts von dieser Bedeutsamkeit.
Mara: Bleibt noch App Service. Das wäre ja meine Wahl. Es wurde für die Arbeit mit Azure DevOps entwickelt und bringt Vorteile mit sich. Es handelt sich um eine Platform-as-a-Service-Umgebung (PaaS) für Web-Apps, was uns einen großen Teil der Last abnimmt. Wir müssen uns nicht um die Infrastruktur kümmern. Es verfügt außerdem über Sicherheitsfunktionen und ermöglicht uns die Vornahme von Lastausgleich und automatischer Skalierung.
Andy: App Service klingt nach dem, was wir brauchen. Benutzen wir also App Service. Wir erstellen ja ohnehin nur einen Proof of Concept. Wir können die Compute-Option jederzeit ändern, wenn wir später etwas anderes ausprobieren möchten.
Wie führt Azure Pipelines Bereitstellungsschritte durch?
Um Ihre Anwendung bereitzustellen, muss sich Azure Pipelines zunächst bei der Zielumgebung authentifizieren. Azure Pipelines bietet verschiedene Authentifizierungsmechanismen. Welche Option Sie verwenden, hängt von der Zielumgebung ab, in der Sie die Bereitstellung vornehmen. Weitere Informationen zu diesen Mechanismen finden Sie am Ende dieses Moduls.
Andy: Wir haben unser Buildartefakt, und wir wissen, dass wir in den Phasen der Pipeline erstellen und bereitstellen werden. Auch die Zielumgebung für unsere Bereitstellung haben wir definiert. Das ist App Service. Meine Frage ist nun, wie authentifiziert sich Azure Pipelines bei App Service? Ich weiß, dass dies eins von Tims Bedenken sein wird. Wir müssen sicherstellen, dass der Prozess sicher ist.
Nach einer kurzen Recherche finden Andy und Mara die allgemeinen Schritte, die es Azure Pipelines ermöglichen, in App Service bereitzustellen:
- Angeben der Zielbereitstellungsumgebung in der Pipelinekonfiguration.
- Bereitstellen einer Möglichkeit für Azure Pipelines, den Zugriff auf diese Umgebung zu authentifizieren.
- Verwenden von Azure Pipelines-Aufgaben, um das Buildartefakt in dieser Umgebung bereitzustellen.
Mara: Laut unseren Recherchen müssen wir eine Dienstverbindung erstellen, um die Zielumgebung anzugeben und den Zugriff darauf zu authentifizieren. Nachdem wir die Dienstverbindung definiert haben, steht sie für alle unsere Aufgaben zur Verfügung. Anschließend müssen wir die integrierte Aufgabe DownloadPipelineArtifact verwenden, um das Buildartefakt in den Pipeline-Agent herunterzuladen, und die Aufgabe AzureWebApp, um unsere Anwendung in Azure App Service bereitzustellen.
Was sind Aufträge und Strategien?
Ihre vorhandene Buildpipeline definiert einen Build-Agent, Pipelinevariablen und die Aufgaben, die zum Erstellen Ihrer Software erforderlich sind.
Der Bereitstellungsteil Ihrer Pipeline enthält dieselben Elemente. Ihre Bereitstellungskonfiguration definiert normalerweise auch einen oder mehrere Aufträge, eine Pipelineumgebung und Strategien. Pipelineumgebungen haben Sie bereits kennengelernt.
Hier sehen Sie eine Beispielkonfiguration, die Sie später in diesem Modul ausführen werden. Diese Konfiguration stellt die Website Space Game in Azure App Service bereit.
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Aufträge
Ein Auftrag ist eine Reihe von Schritten oder Aufgaben, die nacheinander als eine Einheit ausgeführt werden. Jede Pipelinephase hat standardmäßig einen Auftrag, auch wenn diese Phase das Schlüsselwort job nicht verwendet.
Ein Auftrag kann in einem Agentpool, auf einem Container oder direkt auf dem Azure DevOps-Server ausgeführt werden. Der hier gezeigte Beispielauftrag wird auf einem von Microsoft gehosteten Ubuntu-Agent ausgeführt.
Sie können die Bedingungen festlegen, unter denen jeder Auftrag ausgeführt wird. Der hier gezeigte Beispielauftrag definiert keine Bedingungen. Standardmäßig wird ein Auftrag ausgeführt, wenn er von keinem anderen Auftrag abhängig ist, oder wenn alle Aufträge, von denen er abhängig ist, erfolgreich beendet wurden.
Sie können Aufträge auch parallel oder nacheinander ausführen. Mit Ihrer bestehenden Buildpipeline als Beispiel können Sie parallele Aufträge verwenden, um Ihre Software auf Windows-, Linux- und macOS-Agenten gleichzeitig zu erstellen.
Ein Bereitstellungsauftrag ist ein spezieller Auftragstyp, der in Ihren Bereitstellungsphasen eine wichtige Rolle spielt. Bereitstellungsaufträge zeichnen den Status Ihrer Bereitstellungen in Azure Pipelines auf und bieten Ihnen einen Überwachungspfad. Bereitstellungsaufträge helfen Ihnen auch bei der Definition Ihrer Bereitstellungsstrategie, was wir in Kürze machen werden.
Strategien
Eine Strategie definiert, wie das Rollout Ihrer Anwendung durchgeführt wird. Mehr über Strategien wie „Blau-Grün“ (Blue-Green) und „Canary“ erfahren Sie in einem späteren Modul. Vorerst verwenden Sie die Strategie runOnce (einmalige Ausführung), um das Space Game-Paket aus der Pipeline herunterzuladen und in Azure App Service bereitzustellen.
Wie stellt Azure Pipelines eine Verbindung mit Azure her?
Um Ihre App auf einer Azure-Ressource, z. B. einem virtuellen Computer oder in App Service, bereitzustellen, benötigen Sie eine Dienstverbindung. Eine Dienstverbindung bietet sicheren Zugriff auf Ihr Azure-Abonnement über eine von zwei Methoden:
- Dienstprinzipalauthentifizierung
- Verwaltete Identitäten für Azure-Ressourcen
Mehr über diese Sicherheitsmodelle erfahren Sie am Ende dieses Moduls, aber kurzgefasst:
- Ein Dienstprinzipal ist eine Identität mit einer begrenzten Rolle, die auf Azure-Ressourcen zugreifen kann. Stellen Sie sich einen Dienstprinzipal als ein Dienstkonto vor, das automatisierte Aufgaben in Ihrem Namen ausführen kann.
- Verwaltete Identitäten für Azure-Ressourcen sind ein Feature von Microsoft Entra ID, das den Prozess des Arbeitens mit Dienstprinzipalen vereinfacht. Da verwaltete Identitäten auf dem Microsoft Entra-Mandanten existieren, kann die Azure-Infrastruktur den Dienst automatisch authentifizieren und das Konto für Sie verwalten.
Verwaltete Identitäten vereinfachen den Prozess der Zusammenarbeit mit Dienstprinzipalen. In diesem Modul verwenden Sie aber die Dienstprinzipalauthentifizierung, da eine Dienstverbindung Ihre Azure-Ressourcen automatisch ermitteln und ihnen die entsprechenden Dienstprinzipalrollen zuweisen kann.
Der Plan
Andy und Mara sind bereit zu beginnen. Sie gehen wie folgt vor:
- Aufbauen auf ihrer bestehenden Azure Pipelines-Buildkonfiguration.
- Definieren einer Buildphase, die das Artefakt erstellt.
- Definieren einer Bereitstellungsphase, die das Artefakt in App Service bereitstellt.
Andy: Ist diese Zeichnung korrekt? Wir verwenden Azure Pipelines () für die Bereitstellung in App Service (). Dazu nehmen wir das Buildartefakt 
als Eingabe für die Bereitstellungsphase (
). Die Aufgaben in der Bereitstellungsphase laden das Artefakt 
herunter und verwenden eine Dienstverbindung (
), um das Artefakt in App Service bereitzustellen.
Mara: Das bringt es auf den Punkt. Fangen wir also an.