CI/CD für TypeScript-Projekte: GitHub Actions Fortgeschrittene Stufe

Einleitung: Warum braucht man fortgeschrittenes CI/CD für TypeScript?

Eine einfache CI/CD-Pipeline, die nur npm test und npm build ausführt, wird ineffizient, sobald das TypeScript-Projekt wächst. Die Build-Zeit steigt, Tests dauern Stunden und die manuelle Versionsverwaltung führt zu Fehlern. Die fortgeschrittene Konfiguration von GitHub Actions löst diese Probleme: Beschleunigung der Pipeline durch Caching, parallele Tests für verschiedene Node.js-Versionen und Betriebssysteme sowie automatisierte Deployments in die Produktion.

In diesem Artikel behandeln wir drei Schlüsseltechniken für TypeScript-Projekte: intelligentes Caching von node_modules, Matrix-Builds zur Kompatibilitätsprüfung und automatisiertes Deployment mit actions/upload-pages-artifact. Alle Beispiele sind in TypeScript geschrieben und bereit für die Integration in Ihr Repository.

1. Intelligentes Caching von Abhängigkeiten und Kompilierung

Das erste Problem großer TypeScript-Projekte ist die lange Installationszeit von Abhängigkeiten und die Kompilierung. GitHub Actions bietet einen Caching-Mechanismus, der jedoch richtig konfiguriert werden muss. Anstatt den gesamten node_modules-Ordner zu cachen (was zu veralteten Versionen führen kann), ist es besser, package-lock.json und den .cache-Ordner des Compilers zu cachen.

Beispiel für fortgeschrittenes Caching mit TypeScript:

name: TypeScript CI (Advanced)on: [push, pull_request]

jobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4            - name: Setup Node.js        uses: actions/setup-node@v4        with:          node-version: '20'          cache: 'npm'            - name: Cache TypeScript cache        uses: actions/cache@v4        with:          path: |            **/node_modules            **/.tsbuildinfo          key: ${{ runner.os }}-ts-${{ hashFiles('**/package-lock.json') }}          restore-keys: |            ${{ runner.os }}-ts-            - run: npm ci      - run: npm run build --if-present      - run: npm test

Die entscheidende Optimierung hier ist die Verwendung von hashFiles('**/package-lock.json') zur Generierung eines eindeutigen Cache-Schlüssels. Wenn sich package-lock.json nicht geändert hat, wird der Cache in Sekundenschnelle wiederhergestellt. Das Flag --if-present ermöglicht es, das Build-Skript zu überspringen, falls es nicht definiert ist.

2. Matrix-Builds: Testen mit verschiedenen Node.js-Versionen und Betriebssystemen

TypeScript wird in JavaScript kompiliert, aber das Verhalten des Codes kann in verschiedenen Ausführungsumgebungen variieren. Die Matrix-Strategie von GitHub Actions ermöglicht es, dieselbe Pipeline mit mehreren Kombinationen von Betriebssystemen und Node.js-Versionen auszuführen. Dies ist kritisch für Bibliotheken und Serveranwendungen.

Beispiel für die Konfiguration einer Matrix für ein TypeScript-Projekt:

jobs:  test:    runs-on: ${{ matrix.os }}    strategy:      matrix:        os: [ubuntu-latest, windows-latest, macos-latest]        node-version: [18, 20, 22]        exclude:          - os: windows-latest            node-version: 22      fail-fast: false

    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: npx tsc --noEmit      - run: npm test      - name: Upload coverage        uses: actions/upload-artifact@v4        with:          name: coverage-${{ matrix.os }}-${{ matrix.node-version }}          path: coverage/

Wichtige Punkte:

• fail-fast: false — stoppt die anderen Jobs nicht, wenn einer fehlschlägt. Ermöglicht es, alle Probleme auf einmal zu sehen.
• exclude — erlaubt es, bekanntermaßen nicht funktionierende Kombinationen auszuschließen (z. B. Node 22 unter Windows, wenn ein bekanntes Problem vorliegt).