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

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

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

Moderne TypeScript-Entwicklung ist ohne schnelle und zuverlässige Automatisierung nicht möglich. Manuelles Testen, Bauen und Bereitstellen ist nicht nur zeitaufwändig, sondern auch fehleranfällig. Hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel – eine Praxis, die es ermöglicht, Ihren Code automatisch zu überprüfen und bereitzustellen. In diesem Artikel werden wir uns ansehen, wie man eine vollständige CI/CD-Pipeline für TypeScript-Projekte mit GitHub Actions einrichtet – von der grundlegenden Konfiguration bis hin zu fortgeschrittenen Szenarien.

Was ist CI/CD und warum braucht ein TypeScript-Entwickler es?

CI/CD ist eine Methodik, die zwei Praktiken vereint:

Continuous Integration (CI) – Automatisches Bauen und Testen des Codes bei jedem Push ins Repository. Dies ermöglicht eine schnelle Erkennung von Fehlern und Konflikten.
Continuous Deployment/Delivery (CD) – Automatisches Bereitstellen der Anwendung auf einem Server oder in der Cloud, nachdem die Tests erfolgreich bestanden wurden.

Für TypeScript-Projekte ist CI/CD besonders wichtig, da TypeScript in JavaScript kompiliert wird und Fehler in Typen oder der Konfiguration erst während des Build-Prozesses auftreten können. GitHub Actions ist ein integriertes Tool von GitHub, mit dem Sie Ereignisse (Workflows) direkt im Repository erstellen können.

Schritt 1: Basis-Workflow für ein TypeScript-Projekt

Beginnen wir einfach – erstellen Sie eine Datei .github/workflows/ci.yml im Stammverzeichnis Ihres Projekts. Dieser Workflow wird bei jedem Push in den Branch main oder bei der Erstellung eines Pull Requests ausgeführt.

name: CI Pipeline

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

jobs:  build-and-test:    runs-on: ubuntu-latest

    strategy:      matrix:        node-version: [18.x, 20.x]

    steps:      - uses: actions/checkout@v4      - name: Use Node.js ${{ matrix.node-version }}        uses: actions/setup-node@v4        with:          node-version: ${{ matrix.node-version }}          cache: 'npm'      - run: npm ci      - run: npm run build --if-present      - run: npm test      - run: npm run lint --if-present

Lassen Sie uns die wichtigsten Punkte durchgehen:

actions/checkout – Klont das Repository in den Runner.
actions/setup-node – Installiert Node.js mit Caching der Abhängigkeiten.
npm ci – Saubere Installation der Abhängigkeiten (schneller als npm install).
npm run build – Kompiliert TypeScript in JavaScript (stellen Sie sicher, dass Sie ein Skript build in der package.json haben).
npm test – Führt Tests aus (z. B. Jest).

Die Matrix strategy.matrix ermöglicht es, den Code gleichzeitig mit mehreren Node.js-Versionen zu testen – das erhöht die Sicherheit bezüglich der Kompatibilität.

Schritt 2: Linting und Formatierung hinzufügen

Codequalität ist ein wichtiger Teil von CI. Fügen wir Schritte für ESLint und Prettier hinzu. Stellen Sie sicher, dass diese im Projekt installiert sind:

npm install --save-dev eslint prettier eslint-config-prettier

Ergänzen wir unseren Workflow um neue Schritte:

      - run: npm run lint      - run: npm run format:check

In der package.json sollten die entsprechenden Skripte vorhanden sein:

{  "scripts": {    "lint": "eslint src --ext .ts",    "format:check": "prettier --check \\"src/**/*.ts\\"",    "format": "prettier --write \\"src/**/*.ts\\""  }}

Jetzt wird GitHub Actions bei jedem Push nicht nur Typen und Tests überprüfen, sondern auch den Codestil. Wenn der Linter Fehler findet, schlägt die Pipeline fehl und der Entwickler erhält eine Benachrichtigung.