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

Einleitung: Warum CI/CD für TypeScript-Projekte entscheidend ist

Die Entwicklung mit TypeScript ist ein mächtiges Werkzeug, aber ohne Automatisierung der Build-, Test- und Bereitstellungsprozesse riskieren Sie menschliche Fehler, Zeitverlust und Instabilität in der Produktion. CI/CD (Continuous Integration / Continuous Deployment) ist eine Philosophie und eine Reihe von Praktiken, die es ermöglichen, diese Prozesse zu automatisieren. GitHub Actions ist ein integriertes GitHub-Tool, das sich ideal für TypeScript-Projekte eignet und flexible, skalierbare und (für öffentliche Repositories) kostenlose Pipelines bietet.

In diesem Artikel gehen wir den Weg von Null zu einer vollständigen Pipeline: Wir richten Linting, Tests, Build und automatisches Deployment einer TypeScript-Anwendung ein. Sie erfahren, wie Sie effektive YAML-Konfigurationen schreiben, die Ausführungszeit optimieren und typische Fehler vermeiden.

Hauptteil: Schrittweise Erstellung einer CI/CD-Pipeline

1. Grundlagen von GitHub Actions: Struktur eines Workflows

Ein Workflow in GitHub Actions ist eine Reihe von Schritten, die in Jobs zusammengefasst sind. Er wird in einer YAML-Datei beschrieben, die im Verzeichnis .github/workflows/ Ihres Repositorys gespeichert ist. Die grundlegende Struktur sieht so aus:

name: CI/CD Pipeline for TypeScript\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v4\n      - name: Setup Node.js\n        uses: actions/setup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run build\n      - run: npm test

Schlüsselelemente:

\n
• on: — Auslöser (push, pull_request).
\n
• jobs: — Liste der Aufgaben (Jobs), die parallel oder sequenziell ausgeführt werden.
\n
• runs-on: — Betriebssystem für die Ausführung (normalerweise ubuntu-latest).
\n
• steps: — Abfolge von Befehlen. uses ruft vorgefertigte Aktionen (actions) auf, run führt Shell-Befehle aus.
\n
• npm ci — schnelle saubere Installation der Abhängigkeiten basierend auf package-lock.json.
\n

Diese minimale Pipeline bietet bereits eine grundlegende CI: Bei jedem Push oder PR wird der Code auf Build und Tests überprüft.

2. Erweiterte Konfiguration: Linting, Formatierung und Versionsmatrix

Für TypeScript-Projekte ist es entscheidend, einen einheitlichen Codestil beizubehalten. Fügen wir eine Überprüfung mit Linter (eslint) und Formatierer (prettier) hinzu. Außerdem verwenden wir eine Matrix-Strategie, um mit mehreren Node.js-Versionen zu testen.

jobs:\n  lint-and-format:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run format:check\n\n  test:\n    needs: lint-and-format\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node-version: [18, 20, 22]\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\n      - run: npm ci\n      - run: npm test

Wichtige Punkte:

\n
• needs: — legt die Ausführungsreihenfolge der Jobs fest (zuerst Linting, dann Tests).
• strategy.matrix — ermöglicht es, denselben Job mit verschiedenen Parametern (Node.js-Versionen) auszuführen.
• Caching (cache: 'npm') beschleunigt die Installation der Abhängigkeiten.
• Fügen Sie in package.json Skripte hinzu: "lint": "eslint src/" und "format:check": "prettier --check src/".

Jetzt prüft Ihre Pipeline nicht nur