Wie Sie manuelles Deployen aufgeben und keine Angst vor Commits mehr haben
\n\nHaben Sie schon einmal an einem Freitagabend da gesessen, auf die Produktion geschaut und gedacht: "Naja, scheint alles zu funktionieren, aber wenn ich jetzt den Build starte – geht dann nichts kaputt?" Kommt Ihnen bekannt vor? Manuelles Deployment ist wie ein Fallschirmsprung ohne Ausbilder: zwar adrenalingeladen, aber allzu oft endet es schmerzhaft.
\n\nEine CI/CD-Pipeline ist Ihr automatisches Sicherungsseil. Sie baut das Projekt selbstständig, führt Tests durch, prüft den Code und, wenn alles in Ordnung ist, spielt sie das Update auf den Server aus. Kein "Oh, ich habe vergessen, den Build zu starten" oder "Warum sind die Tests fehlgeschlagen, lokal hat doch alles funktioniert?".
\n\nIn diesem Artikel richten wir von Grund auf eine vollwertige CI/CD-Pipeline für ein JavaScript-Projekt ein. Ohne Umschweife, mit echten Codebeispielen und fertigen Konfigurationen. Los geht's!
\n\nWas ist eine CI/CD-Pipeline und warum braucht ein JavaScript-Entwickler sie?
\n\nKlären wir zunächst die Begriffe, damit keine Verwirrung entsteht.
\n\nContinuous Integration (CI) – kontinuierliche Integration. Das bedeutet, dass jeder Ihrer Commits automatisch überprüft wird: Der Code durchläuft Linter, Tests und den Build. Wenn etwas kaputt geht, erfahren Sie es innerhalb von 2 Minuten und nicht erst nach einer Woche.
\n\nContinuous Delivery (CD) – kontinuierliche Bereitstellung. Automatisches Ausrollen des fertigen Codes auf den Server, nachdem alle CI-Prüfungen erfolgreich bestanden wurden.
\n\nFür JavaScript-Projekte ist CI/CD besonders wichtig. Warum? Weil das JS-Ökosystem aus Tausenden von Abhängigkeiten besteht, die sich jederzeit aktualisieren und Ihren Code beschädigen können. Die Automatisierung schützt vor solchen Überraschungen.
\n\nWas wir einrichten werden
\n- \n
- GitHub Actions – ein kostenloses Tool für CI/CD (reicht für die meisten Projekte) \n
- Linter – Prüfung des Codestils (ESLint) \n
- Tests – automatischer Start von Jest \n
- Build – Projekterstellung (Webpack oder Vite) \n
- Deployment – automatisches Hochladen auf den Server oder das Hosting \n
Schritt 1: Projekt vorbereiten
\n\nAngenommen, Sie haben bereits ein JavaScript-Projekt (React, Vue, Node.js – egal). Falls nicht, erstellen Sie ein einfaches Testprojekt:
\n\nmkdir my-ci-cd-project\ncd my-ci-cd-project\nnpm init -y\nnpm install --save-dev jest eslint\n\nFügen wir ein grundlegendes Skript in die package.json ein:
{\n "scripts": {\n "test": "jest",\n "lint": "eslint src/",\n "build": "webpack --mode production",\n "deploy": "rsync -avz dist/ user@server:/var/www"\n }\n}\n\nJetzt haben wir lokale Befehle, die die CI/CD-Pipeline automatisch ausführen wird.
\n\nSchritt 2: GitHub Actions-Workflow erstellen
\n\nGitHub Actions ist das Gehirn unserer Pipeline. Alles wird über YAML-Dateien im Ordner .github/workflows/ gesteuert.
Erstellen Sie die Datei .github/workflows/ci-cd.yml:
name: CI/CD Pipeline\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@v3\n \n - name: Setup Node.js\n uses: actions/setup-node@v3\n with:\n node-version: '18'\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\n \n - name: Build project\n run: npm run build\n\nWas passiert hier? Bei jedem Push in main oder develop startet GitHub eine virtuelle Maschine mit Ubuntu, installiert Node.js 18, installiert die Abhängigkeiten (saubere Installation über npm ci – schneller und zuverlässiger als npm install), prüft den Code mit dem Linter, führt die Tests aus und erstellt das Projekt.
Wenn auch nur ein Schritt fehlschlägt, wird die Pipeline gestoppt und Sie erhalten eine Benachrichtigung.
\n\nSchritt 3: Linter und Tests hinzufügen
\n\nESLint und Jest sind der Standard für JavaScript. Richten wir sie e