Azure Pipelines Tutorial: Ein vollständiger CI/CD-Leitfaden für Einsteiger

Wenn deine CI/CD-Pipeline ständig zusammenbricht oder sich langsam und schwerfällig anfühlt, bist du nicht allein. Ich hatte schon mit fehlgeschlagenen Builds, nicht passenden Umgebungen und Teamkollegen zu tun, die versehentlich meine Arbeit überschrieben haben. Azure Pipelines beseitigt diese Frustrationen mit einem in der Cloud gehosteten Dienst, mit dem fast jedes Projekt auf jeder Plattform erstellt, getestet und bereitgestellt werden kann.

Deshalb zeige ich dir in diesem Tutorial, wie du das machst:

1. Erstelle deine erste Azure Pipeline
2. Baue dein Projekt in der Cloud
3. Füge automatisierte Tests hinzu, um Fehler frühzeitig zu erkennen
4. Bereitstellung in Staging oder Produktion mit einem einzigen Push
5. Überwache und optimiere deine Pipeline für Geschwindigkeit und Zuverlässigkeit
6. Befolge bewährte Praktiken, die sich in realen Projekten bewährt haben

Lass uns loslegen!

Was sind Azure Pipelines?

Azure Pipelines ist eine Cloud-basierte Lösung, die die Entwicklung, das Testen und die Bereitstellung von Anwendungen vereinfacht. 

Es ist eine Komponente des Azure DevOps-Toolkits, das den gesamten Lebenszyklus der Softwareentwicklung unterstützt. Außerdem ist es eine flexible Option für Teams jeder Größe, da es verschiedene Plattformen und Programmiersprachen unterstützt. GitHub, Azure Repos und andere bekannte Versionskontrollsysteme sind darin integriert. 

Zu den wichtigsten Funktionen von Azure Pipelines gehören: 

Meiner Erfahrung nach sind Azure Pipelines für alle hilfreich, die proper CI/CD in ihrem Team haben wollen. Sie ist flexibel, skalierbar und lässt sich gut mit anderen Azure-Diensten integrieren.

Azure Pipelines Architektur (Quelle: Microsoft).

Wenn du ein breiteres Verständnis von Azure DevOps über Pipelines hinaus suchst, ist dieses Azure DevOps-Tutorial waden gesamten CI/CD-Lebenszyklus von Anfang bis Ende durch.

Deine erste Azure Pipeline einrichten

Um mit der Azure Pipelines-Umgebung zu arbeiten, müssen wir zunächst alles so einrichten, dass ein durchgängiger Build-, Test- und Deployment-Prozess möglich ist.

Voraussetzungen

Bevor du mit der Erstellung deiner ersten Pipeline beginnst, solltest du sicherstellen, dass du die folgenden Punkte beachtet hast:

1. Azure DevOps Konto und Organisation einrichten: Melde dich füroder einen Azure DevOps-Accountan, wenn du noch keinen hast. Erstelle eine Organisation, um deine Projekte zu verwalten. 
2. Repository: Du brauchst ein Code-Repository mit einem Beispielprojekt. Diese kann in Azure Repos oder GitHub gehostet werden. Für dieses Tutorial verwenden wir ein einfaches Node.js-Projekt.
3. Zugang zum Azure-Portal: Du brauchst auch Zugang zudem Azure-Portal, wenn du Azure-Dienste wie Azure Kubernetes Service (AKS) und viele andere nutzen willst.

Wenn du dich über das Azure-Ökosystem informieren möchtest, empfehle ich dir den Kurs "Microsoft Azure verstehen". 

Ein neues Projekt und Repository erstellen

Jetzt, wo dein Azure DevOps-Konto und deine Organisation eingerichtet sind, können wir unser erstes Projekt und Repository erstellen.

• Erstelle ein neues Projekt:
  • Melde dich bei deinem Azure DevOps-Konto an.
  • Klicke auf Neues Projekt, gib ihm einen Namen (z. B. "AzureDevOps-DataCamp-Tutorial") und wähle die Sichtbarkeit (öffentlich oder privat).
  • Klicke auf Projekt erstellen.

• Richte ein Repository ein:
  • Wenn du Azure Repos verwendest, navigiere zum AbschnittRepos und initialisiere ein neues Repository.
  • Alternativ kannst du ein bestehendes GitHub-Repository verknüpfen, indem du Repository importieren wählst.
  • Benenne dein Repository, wähle deinen Repository-Typ (Git oder TFVC), füge die URL deines geklonten Repositorys ein und klicke auf Importieren.

• Wenn du GitHubverwendest, kannst du dein GitHub-Konto mit Azure DevOps verknüpfen, indem du unten links in deiner Projektoberfläche auf Projekteinstellungen > GitHub-Verbindungen > Verbinde dein GitHub-Konto.

Für dieses Tutorial verwenden wir Azure Repos als Code-Repository. Wenn du gerade erst anfängst oder keinen bestimmten Grund hast, dich für TFVC zu entscheiden, rate ich dir, Git zu wählen.

Erstellen deiner ersten Pipeline

Es ist an der Zeit, unsere erste Pipeline zu erstellen. Befolge die folgenden Schritte:

• In deinen Pipelines Abschnitt, klicken Sie auf Pipeline erstellen.

• Wähle Azure Repos Git als Quelle und wähle dein Repository aus.

• Du kannst deine Pipeline mit dem YAML- oder Classic-Editor konfigurieren. Nehmen wir YAML, eine codebasierte Methode, um die Pipeline zu definieren.
• Speichere die Pipeline und führe sie aus, um zu sehen, ob alles richtig funktioniert.

Die Wahl zwischen YAML und dem klassischen Editor

Azure Pipelines bietet zwei Möglichkeiten, deine Pipelines zu definieren:

• YAML-Pipelines: Eine codebasierte Möglichkeit, deine Pipeline zu beschreiben. Sie werden in einer .yaml oder .yml Datei in deinem Quellcode-Repository definiert, was die Versionierung und bessere Zusammenarbeit ermöglicht.
• Classic Editor: Der Classic Editor ist eine benutzerfreundliche, visuelle Drag-and-Drop-Oberfläche, die weniger flexibel für komplexe Szenarien ist.

Meiner Erfahrung nach bieten YAML-Pipelines mehr Flexibilität und sind besser für Teams geeignet, dieInfrastructure as Code (IaC) Praktiken ermöglichen. Aber der Classic Editor ist perfekt für alle, die eine visuellere Herangehensweise bevorzugen. 

Für eine langfristige Skalierbarkeit sind YAML-Pipelines jedoch dem klassischen Editor vorzuziehen.

Bauen mit Azure Pipelines

Jetzt wollen wir sehen, wie wir mit Azure Pipelines bauen können. 

In diesem Abschnitt legen wir die Schritte fest, die Azure Pipelines unternimmt, um deinen Code zu erstellen, z. B. die Installation von Abhängigkeiten, die Kompilierung und die Durchführung von Tests. Wir werden diese Schritte in einer Konfigurationsdatei in unserem Quellcode-Repository mit YAML ausdrücken, einer einfachen, für Menschen lesbaren Methode, um Schritte in einem Rezept zu beschreiben.

YAML-Pipeline-Syntax

Hier ist ein einfaches Beispiel für eine YAML-Pipeline:

# This section defines the trigger(s) for the pipeline.
# 'main' specifies that the pipeline will run whenever changes are pushed to the 'main' branch.
trigger:
- main  # automatically triggers this pipeline when changes are made to the 'main' branch.

# This defines the pool where the pipeline will run.
# 'ubuntu-latest' specifies the virtual machine image for executing tasks.
pool:
  vmImage: 'ubuntu-latest'  # This uses the latest Ubuntu image provided by Azure DevOps.

# Steps contain the individual tasks or actions that the pipeline will execute.
steps:
- script: echo Hello, world!  # A script task to run shell commands. This one prints "Hello, world!".
  displayName: 'Run my first pipeline script'  # A friendly name for this step, making it easier to identify in the pipeline logs.Bereitgestellt von

Lass uns den Code Schritt für Schritt aufschlüsseln:

• trigger: Gibt den Zweig an, der die Pipeline auslöst (z. B. main).
• pool: Legt den Build-Agenten fest (z. B. ubuntu-latest).
• steps: Listet die auszuführenden Aufgaben auf, z. B. die Installation von Abhängigkeiten und die Ausführung eines Build-Skripts.

Konfigurieren der Build-Schritte

Um deiner YAML-Pipeline Build-Schritte hinzuzufügen, musst du das "Skript" unter dem Abschnitt "Schritte" definieren.

Für eine einfache Node.js Anwendung zum Beispiel enthält unsere azure-pipelines.yml Datei unten Code, den Azure DevOps automatisch erstellt hat.

# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '20.x'
  displayName: 'Install Node.js'

- script: |
    npm install
    npm run build
  displayName: 'npm install and build'Bereitgestellt von

Werfen wir einen Blick auf den Build steps in der obigen YAML-Pipeline: 

1. Installiere Node.js: Verwende die Aufgabe NodeTool@0, um die Node.js-Version anzugeben. 
2. Installiere die Abhängigkeiten: Führe npm install aus, um die Projektabhängigkeiten zu installieren. 
3. Kompiliere den Code (baue das Projekt): Führe npm run build aus, um den Code zu kompilieren. 

Betrieb der Pipeline

Unsere Pipeline kann manuell ausgelöst oder so eingestellt werden, dass sie automatisch läuft, wenn Ereignisse wie Branch-Pushes eintreten.

• Manueller Auslöser: Klicke auf Run Pipeline in der Azure DevOps-Oberfläche, um die Pipeline manuell auszulösen.

• Automatischer Auslöser: Richte Trigger ein, die auf Repository-Ereignissen basieren, um Änderungen in den Zweig main zu verschieben und die Pipeline automatisch auszulösen. Hier ist ein Beispiel:

trigger:
- mainBereitgestellt von

Nachdem du deine Pipeline ausgeführt hast, kannst du die Protokolle einsehen und eventuelle Probleme beheben.

Um auf die Protokolle zuzugreifen, gehst du zur Zusammenfassung deines Pipeline-Laufs und wählst den entsprechenden Job oder die Aufgabe aus. Wie in der Abbildung unten kannst du jeden Job (Build, Push oder Update) auswählen, um die Rohprotokolle zu sehen.

Um häufige Probleme zu beheben, kannst du deine Pipeline auf häufige Probleme wie Zeitüberschreitungen, Ressourcenbeschränkungen oder Fehlkonfigurationen überprüfen.

Hinzufügen von Tests zu deiner Pipeline

Du fügst deiner Pipeline Tests hinzu, um die Qualität des Codes zu sichern und Probleme in der Entwicklung frühzeitig zu erkennen. In Azure Pipelines kannst du Unit-, Integrations- oder andere Tests integrieren, indem du Schritte in deiner Pipeline-Konfiguration hinzufügst.

Prüfschritte konfigurieren

Baue Testschritte in deine Pipeline ein, um die Codequalität zu gewährleisten. Du kannst beliebte Frameworks wie Jest, Mocha oder NUnit verwenden. Hier siehst du zum Beispiel, wie du mit Jest Unit-Tests hinzufügst:

- script: |
    npm test
  displayName: 'Run unit tests with Jest'Bereitgestellt von

Testergebnisse anzeigen

In Azure Pipelines gibt es eine integrierte Testberichterstattung. Du kannst die Veröffentlichung von Testergebnissen für eine einfachere Nachverfolgung einrichten und die Testergebnisse in den Pipeline-Protokollen einsehen. So geht's:

• Navigieren Sie zunächst zu Builds > Testergebnisse.
• Um Testergebnisse zu veröffentlichen, verwende die Aufgabe PublishTestResults@2, um die Ergebnisse anzuzeigen. Das macht den Lernpfad insgesamt einfacher. Zum Beispiel:

- task: PublishTestResults@2
  inputs:
    testResultsFiles: '**/test-results.xml'
    testRunTitle: 'Unit Tests'Bereitgestellt von

Bereitstellen mit Azure Pipelines

In den Bereitstellungsschritten in deiner Azure-Pipeline-YAML-Datei kannst du deine Anwendung automatisch in verschiedenen Umgebungen bereitstellen, z. B. in der Test-, Staging- und Produktionsumgebung. In diesem Abschnitt gehen wir auf einige Möglichkeiten der Bereitstellung mit Azure Pipelines ein.

Bereitstellen in Azure Web Apps

Azure Web Apps ist ein Dienst im Azure Portal, mit dem du Webanwendungen in großem Umfang entwickeln, bereitstellen und verwalten kannst. 

Für die Bereitstellung in Azure Web Apps musst du die beiden Dienste miteinander verknüpfen. So geht's:

• Gehe unten links in deinem Projekt auf Projekt-Einstellungen und klicke auf . Dienst-Verbindungen unter den Pipelines Abschnitt.

• Klicke auf Neue Serviceverbindung und wählen Sie Azure Ressourcen-Manager.

• Authentifiziere dich mit deinem Azure-Konto.
• Stelle den Azure App Service bereit:
  • Gehe zurück zu deinen Pipelines und konfiguriere deine Pipeline.
  • Füge in deiner Pipeline eine Aufgabe zur Bereitstellung in Azure hinzu.
  • Gib die Ressourcengruppe und die Dienstdetails an. 

Hier ist ein Beispiel für eine YAML-Bereitstellungspipeline für eine einfache Node.js App für Azure App Service:

# Define the task for deploying to an Azure Web App
- task: AzureWebApp@1
  inputs:
    # This specifies your Azure subscription service connection
    azureSubscription: 'your-azure-subscription'
    # This specifies the name of your web app
    appName: 'your-app-name'
    # This specifies the location of the app package or files to be deployed
    package: '$(Build.ArtifactStagingDirectory)'Bereitgestellt von

Lass uns den obigen Code aufschlüsseln, damit du ihn für deinen Anwendungsfall anpassen kannst:

• Ersetze your-azure-subscription durch den Namen der Serviceverbindung, die den Zugang zu deinem Azure-Abonnement ermöglicht.
• Ersetze your-app-name durch den tatsächlichen Namen deiner Web-App in Azure. 
• Ersetze $(Build.ArtifactStagingDirectory) durch das Verzeichnis, in dem das Web-App-Paket oder die Dateien für die Bereitstellung abgelegt werden sollen. $(Build.ArtifactStagingDirectory) - Diese Variable verweist auf den Ordner, in dem sich deine Build-Artefakte (deine App-Dateien) befinden, nachdem sie erstellt worden sind.

Einrichten der kontinuierlichen Bereitstellung (CD)

Wenn unser Code alle Tests und Prüfungen bestanden hat, müssen wir als Nächstes unser Continuous Deployment einrichten. Befolge die unten beschriebenen Schritte.

Azure Release Pipeline Deployment Model (Quelle: Microsoft)

• Erstelle eine Release-Pipeline:
• Gehe zu Pipelines > Freigaben und klicke auf Neue Pipeline.

• Wählen Sie die Azure App Service-Bereitstellung Vorlage.

• Konfiguriere die Umgebungen:
• Hinzufügen und konfigurieren Dev, Staging, QA, und Produktion Umgebungen, in denen deine Anwendung eingesetzt werden soll.

• Verknüpfe das Artefakt aus deiner Build-Pipeline als Quelle für die Release-Pipeline, indem du Artefakt hinzufügen.

• Konfiguriere Genehmigungen und Gates:
• Für sensible Umgebungen, wie z.B. Produktionsumgebungen, ist es notwendig, Genehmigungen vor der Bereitstellung zu erteilen. Zum Beispiel kann es sein, dass ein Teamleiter die Freigabe genehmigen muss. Du kannst auch Gates wie automatische Tests oder Überwachungsprüfungen hinzufügen, um sicherzustellen, dass die Bereitstellung den Qualitätsstandards entspricht.

Meiner Erfahrung nach ist diese Phase notwendig, um die Stabilität in anspruchsvollen Entwicklungsumgebungen zu erhalten. Genehmigungen und Gates sorgen für Kontrolle und stellen sicher, dass nur qualitativ hochwertiger Code in die Produktion gelangt.

Bereitstellung in Kubernetes

Kubernetes macht es einfach, zuverlässige und skalierbare containerisierte Anwendungen zu betreiben. Mit dem Azure Kubernetes Service (AKS) erhältst du eine verwaltete Umgebung, die die Bereitstellung und den Betrieb vereinfacht. In diesem Abschnitt zeige ich dir, wie du deine Anwendung mithilfe von Azure Pipelines in AKS bereitstellst.

Bereite deinen AKS-Cluster vor

Du kannst einen AKS-Cluster über das Azure-Portal oder die CLI erstellen. Hier ist ein einfacher Bash CLI-Befehl zum Bereitstellen von Clustern:

az aks create \
  --resource-group <ResourceGroupName> \
  --name <AKSClusterName> \
  --node-count 3 \
  --enable-addons monitoring \
  --generate-ssh-keysBereitgestellt von

Lasst uns den obigen Befehl aufschlüsseln:

• --resource-group: Dies gibt die Azure-Ressourcengruppe an, in der der AKS-Cluster erstellt werden soll.
• --name: Dies bezieht sich auf den Namen deines AKS-Clusters.
• --node-count: Hier wird die Anzahl der Knoten im Cluster festgelegt (z. B. 3 in diesem Beispiel).
• --enable-addons monitoring: Das macht die Überwachung und Analyse mit Azure Monitor for Containers möglich.
• --generate-ssh-keys: Dadurch werden automatisch SSH-Schlüssel für den sicheren Zugang zum Knotenpunkt generiert, falls keine Angaben gemacht werden.

Vergiss nicht, und durch die tatsächlichen Namen deiner Ressourcengruppe und deines Clusters zu ersetzen.

Kubectl muss konfiguriert werden, nachdem dein AKS-Cluster eingerichtet wurde. Dadurch wird sichergestellt, dass dein Pipeline-Agent oder dein lokaler Computer kubectl verwenden kann, um mit dem Cluster zu kommunizieren.

Du kannst deine Azure-Aufgaben mit Hilfe der Kommandozeile beschleunigen, umols - dieser Azure CLI-Spickzettel ist eine praktische Referenz.

Erstelle eine YAML-Datei für die Bereitstellung 

Nehmen wir als Beispiel eine einfache Deployment-YAML-Datei für das Deployment eines Docker-Images in Kubernetes:

# This defines the API version and the kind of Kubernetes resource we are creating.
# 'apps/v1' is the API version, and 'Deployment' is the resource type.
apiVersion: apps/v1
kind: Deployment

# Metadata contains information to identify the resource uniquely.
# 'name' specifies the name of the Deployment.
metadata:
  name: my-app  # Name of the Deployment, used for identification.

# "spec" specifies the intended deployment state.
spec:
  # Number of replicas/pods we want for this Deployment.
  replicas: 3  # Ensures high availability by running three app replicas.

  # Selector is used to define the labels that this Deployment will manage.
  selector:
    matchLabels:
      app: my-app  # This ensures that only Pods with the label 'app: my-app' are managed by this Deployment.

  # Template specifies the blueprint for the pods created by the Deployment.
  template:
    metadata:
      labels:
        app: my-app  # Labels for the Pods, matching the selector above.

    # A specification for the containers of the Pods.
    spec:
      containers:
      - name: my-app  # Name of the container. This is useful for linking to the container in logs, etc.
        image: mycontainerregistry.azurecr.io/my-app:latest  # Pull the container image you will call from your container registry.
        ports:
        - containerPort: 80  # The container listens on port 80.Bereitgestellt von

Bereitstellen mit Azure Pipelines

Füge in deine YAML-Pipeline eine Aufgabe für die Verteilung an AKS ein.

# This defines a task for deploying Kubernetes manifests within an Azure DevOps pipeline.
- task: KubernetesManifest@0  # Task type for working with Kubernetes manifest files.
  inputs:
    # This configures what to do with the Kubernetes manifest files.
    action: 'deploy'  # 'deploy' action ensures the Kubernetes manifests are applied to the cluster.

    # This defines the namespace where the Kubernetes resources will be deployed.
    namespace: 'default'  # 'default' is the namespace for deploying resources. Change if needed.

    # All this does is point to the manifest files that define the desired state of your Kubernetes resources.
    manifests: '$(Build.ArtifactStagingDirectory)/manifests/*.yaml'
    # The 'manifests' variable points to the location of all the YAML files (e.g., Deployment, Service, etc.) that will be applied during the deployment.

    # To access private container registry images, use the image pull secret.
    imagePullSecrets: 'my-registry-secret'
    # This instructs Kubernetes on which secret to use when pulling images from a private container registry.
    # Ensure that 'my-registry-secret' exists in the namespace before the deployBereitgestellt von

Commit und push die YAML-Datei, um das Deployment auszulösen.

AKS vereinfacht die Container-Orchestrierung und erleichtert die Verwaltung von Skalierung, Updates und Rollbacks. Meiner Erfahrung nach ist es ein Muss für moderne Cloud-native Anwendungen.