CI/CD für JavaScript-Projekte: GitHub Actions von A bis Z

Einleitung: Warum braucht man CI/CD für JavaScript-Projekte?

Die Entwicklung moderner JavaScript-Anwendungen auf Node.js erfordert nicht nur das Schreiben von qualitativ hochwertigem Code, sondern auch dessen zuverlässige Auslieferung an die Endbenutzer. Manuelles Testen, Bauen und Deployment sind nicht nur langsam, sondern auch anfällig für menschliche Fehler. Hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel – eine Methodik zur Automatisierung aller Phasen des Softwarelebenszyklus.

CI/CD für JavaScript-Projekte ermöglicht es, bei jedem Push in das Repository automatisch Tests auszuführen, die Anwendung zu bauen und auf einem Server oder in der Cloud bereitzustellen. Eines der beliebtesten Werkzeuge zur Umsetzung dieser Methodik ist GitHub Actions – das integrierte System zur Automatisierung von Arbeitsabläufen auf der GitHub-Plattform.

In diesem Artikel werden wir durchgehen, wie man eine vollwertige CI/CD-Pipeline für ein JavaScript (Node.js)-Projekt mit GitHub Actions einrichtet: vom Schreiben der Konfiguration bis zum Deployment. Sie erfahren, wie Sie die Entwicklung beschleunigen, die Codequalität verbessern und sich von Routineaufgaben verabschieden können.

Hauptteil: Erstellung einer CI/CD-Pipeline mit GitHub Actions

1. Was ist GitHub Actions und wie funktioniert es?

GitHub Actions ist eine Plattform zur Automatisierung von Arbeitsabläufen (Workflows), die als Reaktion auf Ereignisse im Repository (Push, Pull Request, Erstellung eines Issues usw.) gestartet wird. Ein Workflow ist eine Reihe von Schritten, die auf virtuellen Maschinen (Runnern) ausgeführt werden. Jeder Schritt kann Skripte ausführen, Abhängigkeiten installieren oder externe Dienste aufrufen.

Grundlegende Konzepte:

\n
• Workflow – eine YAML-Konfigurationsdatei, die im Ordner .github/workflows/ gespeichert ist.
\n
• Event – ein Auslöser, der den Workflow startet (z. B. push oder pull_request).
\n
• Job – eine Reihe von Schritten, die auf einem einzigen Runner ausgeführt werden (Abhängigkeiten, Tests, Build).
\n
• Step – ein einzelner Befehl oder eine Aktion (action).
\n

Für JavaScript-Projekte verwenden wir den Standard-Runner mit Ubuntu, da er Node.js von Haus aus unterstützt.

2. Grundeinrichtung: Testen und Linting

Beginnen wir mit der Erstellung eines einfachen Workflows zum Testen und Linting des Codes. Erstellen Sie die Datei .github/workflows/ci.yml im Stammverzeichnis Ihres Repositorys.

Beispielkonfiguration für ein Node.js-Projekt:

name: CI for Node.js\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    strategy:\n      matrix:\n        node-version: [18.x, 20.x]\n\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n\n      - name: Setup Node.js ${{ matrix.node-version }}\n        uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Run linter\n        run: npm run lint\n\n      - name: Run tests\n        run: npm test

Lassen Sie uns die wichtigsten Punkte durchgehen:

\n
• Matrix strategy – ermöglicht das parallele Ausführen von Tests mit mehreren Node.js-Versionen (18.x und 20.x).
\n
• actions/checkout – eine Standardaktion zum Klonen des Repositorys.
\n
• actions/setup-node – installiert die benötigte Node.js-Version und aktiviert das Caching von node_modules zur Beschleunigung.
\n
• npm ci – saubere Installation der Abhängigkeiten aus package-lock.json (schneller und zuverlässiger als npm install).
\n

Nach dem Pushen dieser Datei in das Repository führt GitHub Actions automatisch die Tests aus. Sie sehen das Ergebnis im Bereich "Actions" Ihres Repositorys.

3. Bauen und Veröffentlichen eines Docker-Images

E