CI/CD-Pipeline-Einrichtung in Cursor: Ein vollständiger Leitfaden

Continuous-Integration- und Continuous-Deployment-Pipelines (CI/CD) automatisieren den Build-, Test- und Release-Prozess und ermöglichen es Teams, Code sicher und häufig auszuliefern. Moderne CI/CD umfasst mehrere Plattformen — GitHub Actions für GitHub-gehostete Projekte, GitLab CI für GitLab-Repositories und Jenkins für selbstgehostete, hochgradig anpassbare Pipelines. Cursor ist mit seinem integrierten KI-Assistenten und dem VS Code-kompatiblen Erweiterungsmodell ein hervorragender Editor zum Erstellen und Pflegen von Pipeline-Konfigurationen. Es kann Workflows aus Natural-Language-Prompts generieren, YAML-Syntax validieren und Pipelines refactorn, während sich Ihr Projekt weiterentwickelt.

Dieser Leitfaden behandelt den vollständigen CI/CD-Workflow in Cursor: Konfiguration von GitHub Actions, GitLab CI und Jenkins, Integration automatisierter Tests, Nutzung der KI zum Generieren und Optimieren von Pipeline-Konfigurationen und Befolgen von Best Practices für sichere, zuverlässige Automatisierung.

Einrichtung der CI/CD-Werkzeuge in Cursor

Wesentliche Erweiterungen

Cursor erbt das Erweiterungs-Ökosystem von VS Code. Installieren Sie diese, um die Pipeline-Erstellung zu rationalisieren:

1. YAML (von Red Hat) — Schema-Validierung für GitHub Actions, GitLab CI und Docker Compose-Dateien.
2. GitHub Actions — Syntax-Hervorhebung und Snippets für Workflow-Dateien.
3. GitLab Workflow — GitLab CI-Validierung und MR-Verwaltung.
4. Docker — Dockerfile-Erstellung und Image-Build-Helfer.

tipp

Die YAML-Erweiterung lädt automatisch JSON-Schemata für bekannte Dateitypen herunter. Wenn Sie .github/workflows/deploy.yml erstellen, validiert Cursor die Struktur anhand des offiziellen GitHub Actions-Schemas und bietet Autovervollständigung für jedes Feld.

Projektstruktur für CI/CD

Ein CI/CD-bereites Projekt umfasst typischerweise:

project/
  ├── .github/
  │   └── workflows/
  │       ├── ci.yml
  │       └── deploy.yml
  ├── .gitlab/
  │   └── ci/
  │       └── templates.yml
  ├── .jenkins/
  │   └── Jenkinsfile
  ├── src/
  ├── tests/
  ├── Dockerfile
  ├── docker-compose.yml
  └── package.json

GitHub Actions

Erstellen Ihres ersten Workflows

GitHub Actions verwendet YAML-Dateien in .github/workflows/. Ein grundlegender CI-Workflow läuft bei jedem Push und Pull Request:

# .github/workflows/ci.yml
name: CI

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

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npm run type-check

      - name: Run tests
        run: npm test -- --coverage

      - name: Upload coverage
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 14

tipp

Verwenden Sie npm ci statt npm install in CI. Der ci-Befehl installiert exakte Versionen aus der Lockfile, erzeugt reproduzierbare Builds und schlägt schnell bei Lockfile-Abweichungen fehl.

Matrix-Builds

Testen Sie über mehrere Node.js-Versionen und Betriebssysteme mit einer Matrix:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

Abhängigkeiten cachen

Beschleunigen Sie Workflows durch Caching von Abhängigkeiten und Build-Ausgaben:

- name: Cache npm
  uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

warnung

Cache-Schlüssel, die nur auf dem package-lock.json-Hash basieren, verfehlen, wenn sich die Lockfile ändert. Binden Sie OS und Node-Version in den Schlüssel ein, um Cross-Kontamination zwischen Runner-Umgebungen zu vermeiden.

Wiederverwendbare Workflows

Teilen Sie große Workflows in wiederverwendbare Komponenten auf:

# .github/workflows/reusable-test.yml
name: Reusable Test

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

Rufen Sie es aus einem anderen Workflow auf:

jobs:
  test:
    uses: ./.github/workflows/reusable-test.yml
    with:
      node-version: 20

Deployment-Workflow

Ein Deployment-Job, der nur auf dem main-Branch läuft:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    environment:
      name: production
      url: https://app.example.com
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:latest
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:${{ github.sha }}

      - name: Deploy to ECS
        run: |
          aws ecs update-service --cluster app-cluster --service app-service --force-new-deployment

warnung

Verwenden Sie GitHub Environments mit erforderlichen Reviewern für Produktions-Deployments. Dies fügt ein manuelles Genehmigungs-Gate hinzu, bevor der Deployment-Job ausgeführt wird, und verhindert versehentliche Releases.

GitLab CI

Konfiguration von .gitlab-ci.yml

GitLab CI verwendet eine einzelne .gitlab-ci.yml im Repository-Root:

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/

lint:
  stage: lint
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test -- --coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy:production:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest
  script:
    - ecs update-task-definition --cluster app-cluster --service app-service --image $CI_REGISTRY_IMAGE:$IMAGE_TAG
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  when: manual

tipp

Das rules-Schlüsselwort von GitLab CI ersetzt die ältere only/except-Syntax. Verwenden Sie rules mit if-Bedingungen für eine feinkörnige Kontrolle, wann Jobs ausgeführt werden, und kombinieren Sie mit changes, um Jobs nur auszulösen, wenn relevante Dateien geändert werden.

GitLab CI-Templates

Teilen Sie komplexe Pipelines in Include-Dateien auf:

# .gitlab/ci/test.yml
.test-template:
  stage: test
  image: node:${NODE_VERSION}
  before_script:
    - npm ci
  script:
    - npm test

Binden Sie sie ein:

include:
  - local: .gitlab/ci/test.yml

unit-test:
  extends: .test-template
  script:
    - npm run test:unit

Parallele und Matrix-Jobs

test:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
        OS: ["alpine", "slim"]
  script:
    - npm ci
    - npm test

Jenkins

Schreiben eines Jenkinsfiles

Jenkins-Pipelines verwenden eine Groovy-basierte DSL in einem Jenkinsfile:

// Jenkinsfile
pipeline {
    agent {
        docker {
            image 'node:20-alpine'
            args '-v $HOME/.npm:/root/.npm'
        }
    }

    environment {
        NODE_ENV = 'production'
        DOCKER_IMAGE = "registry.example.com/app:${env.BUILD_NUMBER}"
    }

    options {
        timeout(time: 30, unit: 'MINUTES')
        disableConcurrentBuilds()
        buildDiscarder(logRotator(numToKeepStr: '20'))
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint') {
            steps {
                sh 'npm run lint'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test -- --coverage'
            }
            post {
                always {
                    junit 'reports/junit.xml'
                    publishHTML(target: [
                        reportDir: 'coverage/lcov-report',
                        reportFiles: 'index.html',
                        reportName: 'Coverage Report'
                    ])
                }
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh "docker build -t ${DOCKER_IMAGE} ."
                sh "docker push ${DOCKER_IMAGE}"
                sh "kubectl rollout restart deployment/app -n production"
            }
        }
    }

    post {
        failure {
            emailext subject: "Build failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
                     body: "Check the build at ${env.BUILD_URL}",
                     to: '[email protected]'
        }
        success {
            slackSend channel: '#deploys',
                      message: "Build succeeded: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
        }
    }
}

warnung

Jenkinsfiles werden mit den Berechtigungen des Jenkins-Controllers ausgeführt. Verwenden Sie niemals sh für Befehle mit nicht vertrauenswürdigen Eingaben und zitieren Sie immer interpolierte Variablen, um Shell-Injection zu verhindern.

Deklarative vs. geskriptete Pipeline

Das obige Beispiel verwendet deklarative Syntax. Für komplexe Logik wechseln Sie in geskriptete Blöcke:

stage('Conditional Deploy') {
    steps {
        script {
            def env = params.ENVIRONMENT
            if (env == 'production') {
                input(message: 'Approve production deployment?', ok: 'Deploy')
            }
            sh "./deploy.sh ${env}"
        }
    }
}

Jenkins Shared Libraries

Für wiederverwendbare Pipeline-Logik definieren Sie eine Shared Library:

// vars/npmPipeline.groovy
def call(Map config = [:]) {
    pipeline {
        agent any
        stages {
            stage('Install') {
                steps {
                    sh 'npm ci'
                }
            }
            stage('Test') {
                steps {
                    sh 'npm test'
                }
            }
            stage('Build') {
                steps {
                    sh 'npm run build'
                }
            }
        }
    }
}

Verwenden Sie sie in einem Jenkinsfile:

@Library('my-shared-lib') _

npmPipeline(nodeVersion: '20')

Automatisierte Tests in Pipelines

Unit-Tests

- name: Run unit tests
  run: npm run test:unit -- --reporter=junit --outputFile=reports/junit.xml

Veröffentlichen Sie Ergebnisse in GitHub Actions:

- name: Publish test results
  uses: dorny/test-reporter@v1
  if: always()
  with:
    name: Unit Tests
    path: reports/junit.xml
    reporter: java-junit

Integrationstests

Führen Sie Integrationstests gegen einen Datenbank-Service-Container aus:

jobs:
  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/app_test

tipp

Service-Container in GitHub Actions bieten Wegwerf-Datenbanken für Integrationstests. Binden Sie immer Health-Checks (--health-cmd) ein, damit Ihre Tests nicht starten, bevor die Datenbank bereit ist.

End-to-End-Tests

Führen Sie Playwright E2E-Tests in CI aus:

e2e:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - run: npm ci
    - name: Install Playwright browsers
      run: npx playwright install --with-deps
    - name: Run E2E tests
      run: npx playwright test
    - name: Upload report
      if: always()
      uses: actions/upload-artifact@v4
      with:
        name: playwright-report
        path: playwright-report/

Sicherheits-Scanning

Fügen Sie Abhängigkeits- und Code-Scanning hinzu:

- name: Run audit
  run: npm audit --audit-level=high

- name: CodeQL analysis
  uses: github/codeql-action/init@v3
  with:
    languages: javascript-typescript

- name: Perform analysis
  uses: github/codeql-action/analyze@v3

- name: Trivy container scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: app:latest
    severity: CRITICAL,HIGH

KI-gestützte Pipeline-Konfiguration

Workflows aus Prompts generieren

Die KI von Cursor generiert vollständige Pipeline-Dateien aus Beschreibungen. Öffnen Sie Ctrl+K in einer neuen .yml-Datei und prompten Sie:

Create a GitHub Actions workflow that: runs on push to main and on PRs,
sets up Node 20, installs dependencies with npm ci, runs lint, type-check,
and tests with coverage, builds a Docker image, pushes it to GitHub
Container Registry, and deploys to a Kubernetes cluster using kubectl.
Use caching and environment protections.

Cursor erzeugt einen vollständigen, gültigen Workflow. Überprüfen Sie Berechtigungen und Secrets und verfeinern Sie, indem Sie nach Matrix-Tests oder Slack-Benachrichtigungen fragen.

tipp

Geben Sie beim Prompten für CI/CD-Konfiguration die genaue Plattform und Version an. „GitHub Actions mit Node 20 und Docker buildx" erzeugt weitaus bessere Ausgaben als „eine CI-Pipeline für meine Node-App".

Vorhandene Pipelines optimieren

Cursor kann langsame Pipelines analysieren und optimieren. Markieren Sie die Workflow-Datei und prompten Sie:

Analyze this GitHub Actions workflow and suggest optimizations to reduce
runtime. Identify: missing cache opportunities, jobs that could run in
parallel, oversized images, and unnecessary steps.

Häufige Optimierungsvorschläge der KI:

• Dependency-Caching hinzufügen.
• Lint, Test und Build in parallele Jobs aufteilen.
• Docker-Layer-Caching verwenden.
• Veraltete Läufe für denselben Branch abbrechen.

Pipeline-Tests generieren

Verwenden Sie act, um GitHub Actions lokal vor dem Pushen auszuführen:

# Install act
brew install act

# Run a specific workflow locally
act -j test -W .github/workflows/ci.yml

Prompten Sie Cursor: „Generiere einen Satz von Test-Ereignissen und Mock-Secrets für die lokale Ausführung dieses Workflows mit act."

Secrets-Verwaltung

GitHub Actions Secrets

Speichern Sie Secrets in Repository- oder Environment-Einstellungen, niemals im Code:

- name: Deploy
  env:
    API_KEY: ${{ secrets.API_KEY }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
  run: ./deploy.sh

warnung

GitHub maskiert Secret-Werte in Logs, aber strukturierte Protokollierung kann sie leaken, wenn ein Secret als Teil einer größeren Zeichenkette erscheint. Vermeiden Sie die Protokollierung vollständiger Request-Bodies, die Token enthalten könnten, und verwenden Sie den secrets-Kontext nur in env oder with — niemals in run-Skripten, wo sie echo't werden könnten.

GitLab CI Variablen

deploy:
  variables:
    DATABASE_URL: $CI_DATABASE_URL
  script:
    - ./deploy.sh

Markieren Sie Variablen in der GitLab-Oberfläche als „masked" und „protected", damit sie nur in geschützten Branches erscheinen.

Jenkins Credentials

Verwenden Sie den Credentials Store statt Umgebungsvariablen:

withCredentials([string(credentialsId: 'api-key', variable: 'API_KEY')]) {
    sh './deploy.sh'
}

Best Practices für CI/CD in Cursor

Pipelines schnell halten

• Abhängigkeiten und Build-Ausgaben cachen.
• Unabhängige Jobs parallel ausführen.
• Docker-Layer-Caching für Image-Builds verwenden.
• Laufende Ausführungen abbrechen, wenn ein neuer Commit gepusht wird.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Schnell und laut fehlschlagen

• Lint und Type-Check vor Tests ausführen.
• fail-fast: true bei Matrix-Jobs verwenden, wo ein Fehlschlag die restlichen ungültig macht.
• Bei Fehlschlägen Benachrichtigungen senden (Slack, E-Mail, Teams).

Action-Versionen pinnen

# VERMEIDEN — latest kann unerwartet brechen
- uses: actions/checkout@v4

# BEVORZUGEN — auf einen Commit-SHA pinnen für Reproduzierbarkeit
- uses: actions/[email protected]

tipp

Pinnen Sie Drittanbieter-Actions auf einen vollständigen Commit-SHA, nicht auf einen Tag. Tags können von Maintainern verschoben werden, was ein Supply-Chain-Sicherheitsrisiko darstellt. SHA-Pinning garantiert den exakten Code, der ausgeführt wird.

Environments für Promotion verwenden

GitHub Environments bieten Schutzregeln, erforderliche Reviewer und Deployment-Tracking:

deploy:staging:
  environment: staging

deploy:production:
  needs: deploy:staging
  environment:
    name: production
    url: https://app.example.com

Pipeline-Debugging

Fehlgeschlagene Jobs erneut ausführen

GitHub Actions ermöglicht das erneute Ausführen nur fehlgeschlagener Jobs, was Zeit und Rechenleistung spart:

gh run rerun <run-id> --failed

Debug-Logging aktivieren

- name: Debug step
  env:
    ACTIONS_STEP_DEBUG: true
  run: echo "Detailed logs enabled"

Setzen Sie das Repository-Secret ACTIONS_STEP_DEBUG auf true für ausführliche Runner-Logs.

YAML lokal validieren

Verwenden Sie die YAML-Erweiterung von Cursor, um die Syntax während der Eingabe zu validieren. Für tiefere Validierung verwenden Sie actionlint:

brew install actionlint
actionlint .github/workflows/*.yml

tipp

Cursor kann actionlint beim Speichern mit einer Tasks-Konfiguration ausführen. Fügen Sie einen .vscode/tasks.json-Eintrag hinzu, der actionlint auf die aktuelle Datei ausführt und Fehler im Probleme-Panel anzeigt.

Häufige Fallstricke und wie man sie vermeidet

Veraltete Caches

Ein Cache, der nie invalidiert wird, kann Abhängigkeitsänderungen maskieren. Binden Sie immer den Lockfile-Hash in den Schlüssel ein:

key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

Unbegrenztes Job-Wachstum

Ohne Log-Rotation sammeln sich alte Builds an. Konfigurieren Sie die Aufbewahrung:

# GitHub: in Repository-Einstellungen konfigurieren
# Jenkins:
options {
    buildDiscarder(logRotator(numToKeepStr: '20'))
}

Fehlendes if: always() bei Artefakten

Artefakte eines fehlgeschlagenen Jobs werden standardmäßig nicht hochgeladen. Fügen Sie if: always() hinzu, um Testberichte und Coverage auch bei Fehlschlägen zu erfassen.

warnung

Seien Sie vorsichtig mit if: always() bei Deployment-Schritten — Sie möchten nach einem fehlgeschlagenen Test nicht deployen. Verwenden Sie spezifische Bedingungen wie if: success() && github.ref == 'refs/heads/main'.

Secrets in Logs

Echoen Sie niemals Secrets. Selbst wenn maskiert, treten teilweise Lecks auf, wenn Secrets Teilzeichenfolgen anderer Ausgaben sind. Verwenden Sie Secret-Scanning-Tools und überprüfen Sie Logs beim ersten Deployment manuell.

Zusammenfassung

Cursor ist ein leistungsstarker Editor zum Erstellen und Pflegen von CI/CD-Pipelines über GitHub Actions, GitLab CI und Jenkins. Die YAML-Erweiterung bietet Schema-Validierung, Service-Container ermöglichen Integrationstests, und der KI-Assistent generiert, optimiert und debuggt Pipeline-Konfigurationen aus Natural-Language-Prompts. Beginnen Sie mit dem Scaffolding eines CI-Workflows, fügen Sie automatisierte Tests und Sicherheits-Scans hinzu, und lassen Sie die KI von Cursor die wiederkehrende Konfiguration erledigen, während Sie sich auf die Auslieferung zuverlässiger, schneller und sicherer Deployments konzentrieren.