CI/CD Pipeline – Deployment-Automatisierung in 2026

TL;DR

CI/CD (Continuous Integration/Continuous Deployment) automatisiert Tests, Build und Deployments. Es reduziert Fehler, beschleunigt die Entwicklung und verbessert die Codequalität. Hier erfahren Sie, wie Sie CI/CD-Pipeline in 2026 konfigurieren.

Für wen ist das

• Entwickler, die Deployments automatisieren möchten
• Unternehmen, die DevOps-Praktiken planen
• Teams, die an mehreren Projekten arbeiten

Keywords (SEO)

ci cd pipeline, continuous integration, continuous deployment, github actions, devops automation

Was ist CI/CD?

CI (Continuous Integration):

• Automatische Tests bei jedem Commit
• Frühe Fehlererkennung
• Automatischer Build
• Code-Qualitätsprüfungen

CD (Continuous Deployment/Delivery):

• Automatische Deployments
• Zero-Downtime-Deployments
• Rollback-Fähigkeiten
• Umgebungsmanagement

Vorteile:

• Schnellere Deployments
• Weniger Fehler in Produktion
• Bessere Codequalität
• Mehr Vertrauen in Änderungen

CI/CD-Workflow

1. Entwickler pusht Code

git add .
git commit -m "Add new feature"
git push origin main

2. CI-Pipeline läuft automatisch

Schritte:

1. Lint-Check (ESLint, Prettier)
2. Unit-Tests
3. Integrationstests
4. Build-Anwendung
5. Security-Scan
6. Deploy zu Staging

3. CD-Pipeline deployed in Produktion

Nach CI-Erfolg:

1. Deploy in Produktion
2. Smoke-Tests
3. Health-Checks
4. Rollback bei Fehler

GitHub Actions

Grundkonfiguration

.github/workflows/ci.yml:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linter
      run: npm run lint
    
    - name: Run tests
      run: npm test
    
    - name: Build
      run: npm run build

Deployment-Workflow

.github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build
      run: npm run build
    
    - name: Deploy to production
      run: |
        # Ihr Deployment-Skript
        npm run deploy
      env:
        DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Matrix-Builds (Mehrere Versionen)

jobs:
  test:
    strategy:
      matrix:
        node-version: [16, 18, 20]
        os: [ubuntu-latest, windows-latest, macos-latest]
    
    runs-on: ${{ matrix.os }}
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
    
    - run: npm ci
    - run: npm test

GitLab CI

Grundkonfiguration

.gitlab-ci.yml:

stages:
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "18"

before_script:
  - npm ci

test:
  stage: test
  script:
    - npm run lint
    - npm test
  only:
    - merge_requests
    - main

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour
  only:
    - main

deploy_staging:
  stage: deploy
  script:
    - npm run deploy:staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy_production:
  stage: deploy
  script:
    - npm run deploy:production
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

Jenkins

Jenkinsfile (Pipeline as Code)

pipeline {
    agent any
    
    environment {
        NODE_VERSION = '18'
        DEPLOY_ENV = 'production'
    }
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }
        
        stage('Test') {
            steps {
                sh 'npm run lint'
                sh 'npm test'
            }
        }
        
        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }
        
        stage('Deploy') {
            steps {
                sh 'npm run deploy'
            }
        }
    }
    
    post {
        success {
            echo 'Pipeline succeeded!'
        }
        failure {
            echo 'Pipeline failed!'
        }
    }
}

Best Practices

1. Schnelles Feedback

Schnelle Tests:

• Führen Sie schnelle Tests zuerst aus
• Lange Tests in separaten Jobs
• Parallele Ausführung

jobs:
  quick-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit  # Schnell
  
  slow-tests:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:e2e   # Langsam

2. Dependencies cachen

Schnellere Builds:

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

3. Umgebungsvariablen

Sichere Secrets:

env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

Nicht committen:

• API-Keys
• Passwörter
• Private Keys
• Tokens

4. Bedingte Deployments

Nur von main deployen:

deploy:
  if: github.ref == 'refs/heads/main'
  steps:
    - run: npm run deploy

Manuelle Freigabe:

deploy_production:
  when: manual  # GitLab CI
  # Oder verwenden Sie Environment Protection Rules in GitHub Actions

5. Rollback-Strategie

Automatischer Rollback:

- name: Deploy
  run: npm run deploy

- name: Health check
  run: |
    sleep 30
    curl -f https://example.com/health || exit 1

- name: Rollback on failure
  if: failure()
  run: npm run rollback

6. Benachrichtigungen

Status-Benachrichtigungen:

- name: Notify on failure
  if: failure()
  uses: 8398a7/action-slack@v3
  with:
    status: failure
    text: 'Deployment failed!'
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Deployment-Strategien

1. Blue-Green Deployment

Zwei Umgebungen:

• Blue (Produktion)
• Green (neue Version)

Prozess:

1. Deploy zu Green
2. Tests auf Green
3. Traffic umschalten Blue → Green
4. Blue als Backup

Vorteile:

• Zero Downtime
• Schneller Rollback
• Sichere Deployments

2. Canary Deployment

Schrittweises Deployment:

1. Deploy zu kleiner Benutzergruppe (5%)
2. Überwachung
3. Schrittweise Erhöhung (25%, 50%, 100%)
4. Rollback bei Problemen

Vorteile:

• Frühe Problemerkennung
• Minimaler Impact
• Sicheres Produktionstesten

3. Rolling Deployment

Schrittweise Updates:

1. Server nacheinander aktualisieren
2. Jeder Server kurz offline
3. Health-Checks zwischen Updates

Vorteile:

• Zero Downtime (für mehrere Server)
• Einfaches Deployment
• Ressourceneffizient

Monitoring und Alerting

Health Checks

- name: Health check
  run: |
    for i in {1..10}; do
      if curl -f https://example.com/health; then
        echo "Health check passed"
        exit 0
      fi
      sleep 10
    done
    echo "Health check failed"
    exit 1

Metriken

Überwachen:

• Deployment-Erfolgsrate
• Build-Zeit
• Test-Abdeckung
• Fehlerrate nach Deploy

FAQ

Wie lange dauert CI/CD-Setup?

Für einfaches Projekt: 1-2 Tage. Für komplexes: eine Woche. Lohnenswert, Zeit zu investieren - spart langfristig.

Ist CI/CD für kleine Projekte nötig?

Ja, auch für kleine Projekte. GitHub Actions ist kostenlos für öffentliche Repos, GitLab CI hat auch kostenlosen Tier.

Wie oft deployen?

Hängt vom Projekt ab. Einige Unternehmen deployen mehrmals täglich. Wichtig: kleine, häufige Deploys sind sicherer als große, seltene.

Möchten Sie CI/CD für Ihr Projekt konfigurieren?

• Kontakt