So richten Sie eine CI/CD-Pipeline mit GitHub Actions ein – Leitfaden

CI/CD-Pipeline mit GitHub Actions: Vollständige Einrichtungsanleitung

CI/CD-Pipeline mit GitHub Actions: Vollständige Einrichtungsanleitung

In der modernen Softwareentwicklung ist das manuelle Testen von Code und das Ausführen von Bereitstellungsskripten nach jeder Änderung ein Engpass, der die Auslieferung verlangsamt und menschliche Fehler verursacht. Eine CI/CD-Pipeline automatisiert diesen gesamten Prozess – vom Testen des Codes bis zur Bereitstellung in der Produktion. Diese Anleitung zeigt Ihnen, wie Sie eine CI/CD-Pipeline mit GitHub Actions, einer leistungsstarken und integrierten Automatisierungsplattform, mit praktischen, realen YAML-Beispielen einrichten, sodass Sie Code schneller und zuverlässiger ausliefern können.

Was Sie lernen werden

Am Ende dieser Anleitung verstehen Sie die Kernkonzepte von Continuous Integration und Continuous Deployment (CI/CD) und können eine mehrstufige Pipeline mit GitHub Actions implementieren. Sie lernen, Workflows für automatisiertes Testen, das Erstellen von Docker-Images und die Bereitstellung von Anwendungen zu schreiben. Sie erhalten funktionierenden YAML-Code zum Testen, Erstellen und Bereitstellen Ihrer eigenen Projekte – egal ob es sich um Python-, Node.js- oder containerisierte Anwendungen handelt.

Grundlagen von GitHub Actions verstehen

GitHub Actions ist eine ereignisgesteuerte Automatisierungsplattform, die direkt in GitHub-Repositorys integriert ist. Sie ermöglicht die Ausführung automatisierter Workflows, die durch Ereignisse wie push, pull_request oder release ausgelöst werden. Im Kern wird ein Workflow in einer YAML-Datei im Verzeichnis .github/workflows/ definiert und besteht aus einem oder mehreren Jobs, die standardmäßig parallel ausgeführt werden, wobei jeder eine Reihe von Schritten enthält.

Kernkomponenten

• Ereignis (on): Der Auslöser, der den Workflow startet, z. B. push auf einen bestimmten Branch oder ein pull_request.
• Runner (runs-on): Die Maschine, auf der der Job ausgeführt wird. ubuntu-latest ist die gängigste und empfohlene Wahl aufgrund ihrer Leistung und breiten Softwareverfügbarkeit.
• Schritte: Einzelne Aufgaben innerhalb eines Jobs. Dies können Shell-Skripte (run) oder vorgefertigte Aktionen (uses) aus dem GitHub Marketplace sein.
• Aktionen: Wiederverwendbare Code-Einheiten, wie actions/checkout@v4 zum Klonen Ihres Repositorys oder actions/setup-node@v4 zur Installation von Node.js.

Ein einfacher Workflow für den Einstieg

Der einfachste Workflow kann bei jedem Push ausgelöst werden. Erstellen Sie eine Datei unter .github/workflows/main.yml, um einen einfachen "Hallo Welt"-Befehl auszuführen.

name: beispiel
on: push
jobs:
  begruessung:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hallo, CI/CD-Welt!"

Nachdem Sie diese Datei in Ihr Repository übertragen und gepusht haben, können Sie die Ausgabe des Jobs im Tab "Actions" Ihres GitHub-Repositorys anzeigen.

Aufbau einer umfassenden CI-Pipeline

Der "CI"-Teil einer Pipeline stellt sicher, dass Codeänderungen automatisch getestet und verifiziert werden, bevor sie zusammengeführt werden. Dies umfasst typischerweise Linting, Typprüfung und das Ausführen von Unit-Tests.

Die CI-Workflow-Datei

Erstellen Sie .github/workflows/ci.yml. Dieser Workflow wird bei jedem push und pull_request auf den main-Branch ausgelöst. Das folgende Beispiel zeigt eine vollständige Pipeline für ein Node.js-Projekt, das Schema lässt sich jedoch auf andere Sprachen wie Python mit actions/setup-python übertragen.

name: CI-Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

Erläuterung der wichtigsten Funktionen

1. Abhängigkeits-Caching: Die Option cache: 'npm' in actions/setup-node beschleunigt den Workflow erheblich, indem Abhängigkeiten aus früheren Läufen wiederverwendet werden.
2. Job-Abhängigkeiten: Das Schlüsselwort needs definiert die Ausführungsreihenfolge. Beispielsweise wird der build-Job nur ausgeführt, wenn die lint- und test-Jobs erfolgreich waren. Dies verhindert Zeitverschwendung durch das Erstellen fehlerhaften Codes.
3. Umgebungsvariablen: Für Dienste wie Datenbanken können Sie Umgebungsvariablen definieren. Beispielsweise kann ein test-Job einen PostgreSQL-Dienstcontainer starten und mit env eine Verbindung herstellen.

Fortgeschrittene Szenarien: Containerisierte und Multi-Umgebungs-Bereitstellungen

Bei modernen Anwendungen umfasst die Pipeline oft das Erstellen von Container-Images und deren Bereitstellung. Die folgende Tabelle zeigt gängige Bereitstellungsstrategien und deren Auslöser.

Vergleich der Bereitstellungsauslöser

Strategie	Bereitstellungsauslöser	Am besten geeignet für
Branch-basiert	push auf main	Kontinuierliche Bereitstellung des neuesten Entwicklungscodes.
Tag-basiert	push eines neuen Tags (z. B. v1.0.0)	Veröffentlichung stabiler, versionierter Software in der Produktion.
Release-basiert	release auf GitHub veröffentlicht	Offizielle Produktveröffentlichungen, die auch Versionshinweise generieren.

Beispiel: Bereitstellung eines Docker-Containers mit einem CI/CD-Workflow

Dieses umfassende Beispiel zeigt eine Pipeline, die eine Python-Anwendung testet, ein Docker-Image erstellt und in eine Registry pusht. Es verwendet eine Reihe offizieller Docker-Aktionen für einen sicheren, leistungsstarken Build.

Erstellen Sie .github/workflows/deploy.yml:

name: Vollständige CI/CD-Pipeline

on:
  push:
    branches: [ main ]
  release:
    types: [published]

env:
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
  DOCKER_HUB_TOKEN: ${{ secrets.DOCKER_HUB_TOKEN }}
  IMAGE_NAME: my-app

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      - run: pip install -r requirements.txt
      - run: pytest

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'
    steps:
      - uses: actions/checkout@v4
      - name: Docker Buildx einrichten
        uses: docker/setup-buildx-action@v3
      - name: Bei Docker Hub anmelden
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_TOKEN }}
      - name: Metadaten extrahieren
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=raw,value=latest,enable={{is_default_branch}}
      - name: Erstellen und pushen
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.event_name == 'release'
    steps:
      - name: Bereitstellungsskript ausführen
        run: |
          echo "Bereitstellung des Images ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}:${{ github.event.release.tag_name }}"

Wichtig: Verwaltung von Geheimnissen

Damit der obige Workflow funktioniert, müssen Sie Ihre Anmeldeinformationen sicher in Ihrem GitHub-Repository speichern. Navigieren Sie zu Einstellungen > Geheimnisse und Variablen > Aktionen und fügen Sie die folgenden Geheimnisse hinzu:

1. DOCKER_HUB_USERNAME: Ihr Docker Hub-Benutzername.
2. DOCKER_HUB_TOKEN: Ein persönliches Zugriffstoken von Docker Hub mit Lese-/Schreibberechtigungen.

⚠️ Sicherheitswarnung: Härten Sie niemals Passwörter, Token oder andere sensible Daten direkt in Ihren YAML-Dateien. Verwenden Sie immer GitHub-Geheimnisse, die verschlüsselt und nur während der Workflow-Ausführung zugänglich sind.

Häufig gestellte Fragen

Was sind die ersten Schritte zum Einrichten einer CI/CD-Pipeline mit GitHub Actions?

Erstellen Sie zunächst ein .github/workflows-Verzeichnis in Ihrem Repository. Erstellen Sie darin eine YAML-Datei (z. B. ci.yml) und definieren Sie Ihren name, on (Auslöserereignisse wie push) und jobs (die auszuführenden Aufgaben). Übertragen und pushen Sie diese Datei, um Ihren ersten automatisierten Workflow zu starten.

Kann ich GitHub Actions verwenden, um Tests bei Pull-Requests auszuführen?

Ja, das Testen bei Pull-Requests ist ein Kernanwendungsfall. Indem Sie den on-Auslöser auf pull_request für den main-Branch setzen, wird der Workflow bei jedem neuen Pull-Request automatisch ausgeführt und stellt die Codequalität vor dem Zusammenführen sicher.

Wie erstelle und pushe ich ein Docker-Image mit einem GitHub Actions-Workflow?

Sie können offizielle zusammengesetzte Aktionen wie docker/login-action, docker/setup-buildx-action und docker/build-push-action verwenden. Dies vereinfacht den Prozess, übernimmt automatisch die Authentifizierung und ermöglicht Funktionen wie Build-Caching und Multi-Plattform-Builds.

Ist es möglich, mit GitHub Actions auf GitHub Pages bereitzustellen?

Ja. Sie können die Community-Aktion JamesIves/github-pages-deploy-action verwenden. Sie konfigurieren sie mit dem Ordner, der Ihre erstellte Website enthält, und sie übernimmt die git-Operationen, um die Änderungen auf den gh-pages-Branch zu übertragen und zu pushen.

Was ist der Unterschied zwischen einem push- und einem release-Ereignisauslöser?

Ein push-Ereignis löst den Workflow aus, sobald Code auf einen bestimmten Branch gepusht wird. Ein release-Ereignis wird ausgelöst, wenn eine GitHub-Version veröffentlicht wird. push wird typischerweise für CI- und Staging-Bereitstellungen verwendet, während release oft für die Bereitstellung in der Produktion genutzt wird.

Quellen

• Set up GitHub Actions CI/CD pipeline · Issue #176 (Praktische YAML-Beispiele für CI, E2E und Bereitstellung)
• DevOps: Set up GitHub Actions CI/CD pipeline · Issue #19 (Zeigt Linting, Typprüfung und Build-Verifizierung)
• GitHub - kamrun111/GitHubActionTest (Ein einfaches, anfängerfreundliches Python-CI/CD-Beispiel)
• @jamesives/github-pages-deploy-action (Dokumentation zur Bereitstellung auf GitHub Pages)
• GitHub - CarlosQuintero8/cicdsimulation (Zeigt eine mehrstufige Pipeline mit Testen, Erstellen und Bereitstellung auf GitHub Pages)
• GitHub - anuragstark/Py-app-CI-CD-Pipeline- (Umfassende Anleitung inklusive Docker- und Minikube-Bereitstellung)
• Automated CI/CD with GitHub Actions, starting from scratch (Eine Schritt-für-Schritt-Anleitung zum inkrementellen Aufbau von CI/CD-Workflows)
• Extend App with GitHub Actions · AccelByte Documentation (Beispiel für eine durch ein Release-Ereignis ausgelöste Bereitstellung)
• Configure CI/CD for your C++ application · Docker Docs (Zeigt die Einrichtung von GitHub Actions mit Docker Hub)
• Hello CI World · HSF Training (Ein einfaches Tutorial zum Erstellen und Ausführen eines ersten Workflows)

— Editorial Team