Jenkins vs GitLab CI vs GitHub Actions - Welches CI/CD-Tool sollten Sie waehlen?

Continuous Integration und Continuous Delivery (CI/CD) sind die Grundpfeiler moderner Softwareentwicklung. Die Automatisierung von Build-, Test- und Deployment-Prozessen ermoeglicht es Teams, Software schneller, zuverlaessiger und mit groesserer Wiederholbarkeit auszuliefern. Die Wahl des richtigen CI/CD-Tools hat direkten Einfluss auf die Teamproduktivitaet, Infrastrukturkosten und die Qualitaet der ausgelieferten Software.

In diesem Artikel vergleichen wir die drei beliebtesten CI/CD-Plattformen im Detail: Jenkins - den Automatisierungsveteranen, GitLab CI/CD - die integrierte DevOps-Plattform, und GitHub Actions - das moderne, in den weltweit beliebtesten Code-Hosting-Dienst integrierte Tool. Wir analysieren jedes Tool hinsichtlich Architektur, Pipeline-Syntax, Docker-Integration, Secrets-Management, Preisgestaltung und Einsatzszenarien, damit Sie eine fundierte Entscheidung treffen koennen.

Architektur - Wie sie unter der Haube funktionieren#

Jenkins - Master-Agent-Architektur#

Jenkins basiert auf einem Master-Agent-Modell (frueher Master-Slave). Der Hauptserver (Controller) verwaltet die Konfiguration, die Job-Planung und die Weboberflaeche, waehrend die Agents (Nodes) die eigentlichen Build-Aufgaben ausfuehren. Diese Architektur ermoeglicht die verteilte Pipeline-Ausfuehrung auf verschiedenen Maschinen und Betriebssystemen.

Zentrale Architekturkomponenten von Jenkins:

Controller (Master) - zentraler Server, der Job-Queue, Konfiguration und UI verwaltet
Agents (Nodes) - Maschinen, die Builds ausfuehren, verbunden ueber SSH, JNLP oder WebSocket
Executors - Threads auf Agents, jeder bearbeitet einen Build gleichzeitig
Plugins - ueber 1.800 Plugins zur Erweiterung der Basisfunktionalitaet
Shared Libraries - wiederverwendbare Groovy-Bibliotheken zum Teilen von Pipeline-Logik

Jenkins erfordert eine selbstverwaltete Installation auf einem Server (physisch, VM oder Container). Es gibt keine native Cloud-Loesung - Sie verwalten immer Ihre eigene Infrastruktur.

GitLab CI/CD - Integrierte DevOps-Plattform#

GitLab CI/CD ist direkt in die GitLab-Plattform integriert, sodass Sie kein separates CI/CD-System konfigurieren muessen. Die Architektur basiert auf GitLab Runners - leichtgewichtigen Agents, die in der .gitlab-ci.yml-Datei definierte Jobs ausfuehren.

Zentrale Architekturkomponenten von GitLab CI/CD:

GitLab Server - verwaltet Pipelines, speichert Konfiguration und Ergebnisse
GitLab Runners - Agents zur Job-Ausfuehrung (Shared, Group oder Project Runners)
Executors - Art der Job-Ausfuehrung: Shell, Docker, Docker Machine, Kubernetes, VirtualBox
Container Registry - integrierte Docker-Image-Registry
Artifacts & Cache - nativer Speicher fuer Artefakte und Cache zwischen Jobs

GitLab bietet ein hybrides Modell: Sie koennen gitlab.com (SaaS) nutzen oder GitLab self-hosted (CE/EE) installieren. Runner koennen gemeinsam genutzt (GitLab-hosted) oder privat (self-hosted) sein.

GitHub Actions - Event-gesteuerte Automatisierung#

GitHub Actions verfolgt eine event-gesteuerte Architektur - Workflows werden durch Repository-Events ausgeloest (Push, Pull Request, Release, Issue, Cron und mehr). Jeder Workflow besteht aus Jobs, und jeder Job besteht aus Steps.

Zentrale Architekturkomponenten von GitHub Actions:

Workflows - YAML-Dateien im Verzeichnis .github/workflows/, die Automatisierungen definieren
Jobs - Gruppen von Steps, die auf einem einzelnen Runner laufen, standardmaessig parallel
Steps - einzelne Befehle oder Actions aus dem Marketplace
Runners - Maschinen zur Job-Ausfuehrung: GitHub-hosted (Ubuntu, Windows, macOS) oder self-hosted
Actions - wiederverwendbare Komponenten aus dem Marketplace oder eigenen Repositories

GitHub Actions ist nativ in GitHub integriert und laeuft standardmaessig in der Cloud. Self-hosted Runner sind optional fuer spezielle Anforderungen.

Pipeline-Syntax - Vergleich#

Einer der wichtigsten Aspekte bei der Wahl eines CI/CD-Tools ist die Syntax zur Pipeline-Definition. Jedes der drei Tools bietet einen anderen Ansatz.

Jenkins - Jenkinsfile (Groovy)#

Jenkins bietet zwei Arten von Pipelines: deklarativ (einfacher, strukturiert) und skriptbasiert (volle Groovy-Power). Das Jenkinsfile liegt im Repository neben dem Code.

// Jenkinsfile - deklarative Pipeline
pipeline {
    agent {
        docker {
            image 'node:20-alpine'
        }
    }

    environment {
        CI = 'true'
        NODE_ENV = 'test'
    }

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

        stage('Lint & Test') {
            parallel {
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Unit Tests') {
                    steps {
                        sh 'npm run test:unit'
                        junit 'reports/junit.xml'
                    }
                }
                stage('Integration Tests') {
                    steps {
                        sh 'npm run test:integration'
                    }
                }
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
                archiveArtifacts artifacts: 'dist/**/*'
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                withCredentials([string(credentialsId: 'deploy-token', variable: 'TOKEN')]) {
                    sh './scripts/deploy.sh'
                }
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build Failed: ${env.JOB_NAME}",
                 body: "Check: ${env.BUILD_URL}"
        }
        always {
            cleanWs()
        }
    }
}

Vorteile: Volle Programmiersprachen-Power (Groovy), Moeglichkeit komplexer Bedingungen und Schleifen, Shared Libraries zum projektuebergreifenden Teilen von Logik.

Nachteile: Steile Lernkurve fuer Groovy, schwierigeres Debugging, kein natives IDE-Auto-Complete fuer die Pipeline-DSL.

GitLab CI/CD - .gitlab-ci.yml (YAML)#

GitLab definiert Pipelines in einer .gitlab-ci.yml-Datei im Repository-Root. Die Syntax ist deklarativ und YAML-basiert.

# .gitlab-ci.yml
image: node:20-alpine

variables:
  CI: "true"
  NODE_ENV: test

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/

stages:
  - install
  - test
  - build
  - deploy

install:
  stage: install
  script:
    - npm ci --cache .npm

lint:
  stage: test
  script:
    - npm run lint
  needs: [install]

unit-tests:
  stage: test
  script:
    - npm run test:unit
  artifacts:
    reports:
      junit: reports/junit.xml
  needs: [install]

integration-tests:
  stage: test
  script:
    - npm run test:integration
  services:
    - postgres:15
    - redis:7
  needs: [install]

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy-production:
  stage: deploy
  script:
    - ./scripts/deploy.sh
  environment:
    name: production
    url: https://example.com
  only:
    - main
  when: manual

Vorteile: Lesbares YAML, einfache Service-Definitionen (Datenbanken, Caches), integrierte Environments, needs-Keyword zur DAG-Erstellung.

Nachteile: YAML kann ausfuehrlich werden, eingeschraenkte Moeglichkeiten fuer bedingte Logik (rules vs only/except), schwierigeres Debugging komplexer Pipelines.

GitHub Actions - Workflow YAML#

GitHub Actions definiert Workflows in YAML-Dateien im Verzeichnis .github/workflows/. Jede Datei ist ein separater Workflow mit eigenen Triggern.

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

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

env:
  CI: true
  NODE_ENV: test

jobs:
  install:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci

  lint:
    needs: install
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    needs: install
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-type: [unit, integration]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run test:${{ matrix.test-type }}

  build:
    needs: [lint, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/
      - run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Vorteile: Intuitives YAML, wiederverwendbare Actions aus dem Marketplace, Matrix Builds, explizite Event-Trigger, integrierte Expressions.

Nachteile: Jeder Job startet einen neuen Runner (kein gemeinsamer Zustand zwischen Jobs), Dateien koennen bei komplexen Workflows ausfuehrlich werden.

Einrichtung und Einstieg#

Jenkins - Erfordert den groessten Aufwand#

Die Einrichtung von Jenkins von Grund auf erfordert:

Installation von Java (JDK 11+) auf einem Server
Download und Start des Jenkins-WAR oder Systempakets
Durchlaufen des Setup-Assistenten (Plugin-Auswahl, Admin-Erstellung)
Konfiguration der Build-Agents
Erstellung einer Pipeline und Verbindung mit einem Repository
Einrichtung von Webhooks fuer automatische Trigger

Zeit bis zur ersten funktionierenden Pipeline: 1-4 Stunden (mehr bei Docker-/Kubernetes-Agents).

GitLab CI/CD - Mittlere Komplexitaet#

Bei Nutzung von gitlab.com:

.gitlab-ci.yml-Datei im Repository erstellen
Pipeline startet automatisch beim naechsten Push

Bei self-hosted GitLab:

GitLab installieren (Omnibus, Docker oder Helm)
Runner registrieren (gitlab-runner register)
.gitlab-ci.yml erstellen

Zeit bis zur ersten Pipeline: 5-15 Minuten (gitlab.com) oder 1-2 Stunden (self-hosted).

GitHub Actions - Schnellster Einstieg#

.github/workflows/ci.yml-Datei im Repository erstellen
Push zu GitHub
Pipeline startet automatisch

GitHub bietet auch fertige Pipeline-Vorlagen (Starter Workflows) fuer populaere Sprachen und Frameworks.

Zeit bis zur ersten Pipeline: 2-5 Minuten.

Self-Hosted vs Cloud - Hosting-Modelle#

Jenkins - Ausschliesslich Self-Hosted#

Jenkins ist von Natur aus eine Self-Hosted-Loesung. Sie muessen Infrastruktur, Updates, Sicherheit und Skalierung selbst verwalten. Das gibt volle Kontrolle, erfordert aber ein dediziertes DevOps-Team.

Vorteile: Volle Kontrolle ueber Daten und Infrastruktur, keine Limits bei Build-Minuten, Betrieb in Air-Gapped-Netzwerken moeglich, Einhaltung strenger regulatorischer Anforderungen.

Nachteile: Infrastruktur-Wartungskosten (Server, Monitoring, Backups), Verantwortung fuer Sicherheit und Updates, manuelles Skalieren erforderlich, dedizierter Administrator noetig.

GitLab CI/CD - Hybrides Modell#

GitLab bietet zwei Modelle: vollstaendig verwaltete Cloud (gitlab.com) oder Self-Hosted-Installation (GitLab CE/EE). Runner koennen gemeinsam genutzt (GitLab-hosted) oder privat (self-hosted) sein. Das bietet grosse Flexibilitaet - Sie koennen z.B. gitlab.com fuer Code-Hosting nutzen, aber Builds auf eigenen Runnern ausfuehren.

Vorteile: Flexible Wahl zwischen Cloud und Self-Hosted, Moeglichkeit zum Mischen von Runner-Typen, integrierte Container Registry, Auto DevOps fuer automatische Konfiguration.

Nachteile: Shared Runner koennen langsam sein und haben begrenzte Ressourcen, Self-Hosted erfordert Verwaltung, Ultimate-Plan ist teuer.

GitHub Actions - Cloud-First mit Self-Hosted-Option#

GitHub Actions laeuft standardmaessig in der Cloud auf GitHub-hosted Runnern (Ubuntu, Windows, macOS). Runner haben vorinstallierte populaere Tools (Docker, Node.js, Python, Java, .NET). Self-hosted Runner sind eine Option fuer spezielle Anforderungen (GPUs, spezifische Hardware, private Netzwerke).

Vorteile: Keine Infrastruktur-Konfiguration noetig, fertige Umgebungen mit vorinstallierten Tools, automatische Updates, native GitHub-Integration.

Nachteile: Minuten-Limits im kostenlosen Plan, macOS-Runner sind teuer, eingeschraenkte Kontrolle ueber Hosted-Runner-Umgebungen, Self-hosted Runner erfordern zusaetzliche Sicherheitskonfiguration.

Plugin-Oekosystem und Marketplace#

Jenkins - Der Plugin-Koenig#

Mit ueber 1.800 Plugins bietet Jenkins das breiteste Erweiterungs-Oekosystem aller CI/CD-Tools. Sie finden Plugins zur Integration mit praktisch jedem Tool: SonarQube, Artifactory, AWS, Azure, GCP, Slack, Jira, Docker, Kubernetes und viele mehr.

// Beispiel fuer Docker-Plugin im Jenkinsfile
pipeline {
    agent {
        docker {
            image 'maven:3.9-eclipse-temurin-21'
            args '-v $HOME/.m2:/root/.m2'
        }
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests'
            }
        }
        stage('SonarQube-Analyse') {
            steps {
                withSonarQubeEnv('sonar-server') {
                    sh 'mvn sonar:sonar'
                }
            }
        }
    }
}

Nachteile: Plugin-Qualitaet variiert, einige sind aufgegeben oder veraltet, Versionskonflikte zwischen Plugins sind ein haeufiges Problem, Plugin-Updates koennen bestehende Pipelines beeintraechtigen.

GitLab CI/CD - Integrierte Funktionalitaet#

GitLab setzt auf integrierte Funktionalitaet statt Plugins. Die meisten Funktionen (Container Registry, Package Registry, Security Scanning, Monitoring, Wiki, Issue Tracker) sind Teil der Plattform. CI/CD-Vorlagen stehen zum Importieren und Erweitern zur Verfuegung.

# Verwendung vorgefertigter GitLab-Vorlagen
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Code-Quality.gitlab-ci.yml

# Ueberschreiben der Vorlagen-Konfiguration
sast:
  variables:
    SAST_EXCLUDED_PATHS: "tests/, docs/"

Vorteile: Enge Integration zwischen Funktionen, keine Plugin-Kompatibilitaetsprobleme, einheitliche Oberflaeche.

Nachteile: Weniger flexibel als ein Plugin-System, erweiterte Funktionen (SAST, DAST) nur im teuren Ultimate-Plan verfuegbar.

GitHub Actions - Marketplace#

Der GitHub Actions Marketplace bietet tausende fertige Actions, erstellt von der Community, Anbietern und GitHub selbst. Jede Action ist ein GitHub-Repository, das durchsucht, geforkt und modifiziert werden kann.

# Beispiel fuer Marketplace-Actions
steps:
  - uses: docker/build-push-action@v5
    with:
      context: .
      push: true
      tags: myapp:latest
      cache-from: type=gha
      cache-to: type=gha,mode=max

  - uses: sonarsource/sonarqube-scan-action@v2
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

  - uses: slackapi/slack-github-action@v1
    with:
      payload: '{"text": "Deploy abgeschlossen!"}'
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Vorteile: Riesige Community, einfache Erstellung eigener Actions (Docker oder JavaScript), Action-Versionierung (Pinning auf SHA), Reusable Workflows.

Nachteile: Risiko von Supply-Chain-Angriffen (verwendete Actions muessen auditiert werden), einige Anbieter geben ihre Actions auf, keine zentrale Qualitaetskontrolle.

Preismodelle#

Jenkins - Kostenlos, aber Infrastrukturkosten#

Jenkins ist vollstaendig kostenlos und Open Source (MIT-Lizenz). Die realen Kosten umfassen jedoch:

Infrastruktur (Server, Storage, Netzwerk) - von 100 bis 1.000+ USD/Monat
Teamzeit fuer Wartung, Updates und Fehlerbehebung
Optionale kommerzielle Distributionen (CloudBees CI) - ab 3.000 USD/Jahr

Geschaetzte monatliche Kosten fuer ein Team von 10 Entwicklern: 200-800 USD fuer Infrastruktur plus DevOps-Arbeitskosten.

GitLab CI/CD#

| Plan | Preis/Nutzer/Monat | CI-Minuten/Monat | Wichtige CI/CD-Funktionen | |------|-------------------|-----------------|--------------------------| | Free | 0 USD | 400 Min. | Grundlegendes CI/CD, 5 GB Speicher | | Premium | 29 USD | 10.000 Min. | Merge Trains, Code Review, Protected Environments | | Ultimate | 99 USD | 50.000 Min. | SAST/DAST, Security Dashboard, Compliance |

Zusaetzliche Minuten: Linux 0,005 USD/Min., Windows 0,01 USD/Min., macOS - nicht auf Shared Runnern verfuegbar.

GitHub Actions#

| Plan | Preis | Minuten/Monat | Storage | |------|-------|--------------|---------| | Free | 0 USD | 2.000 Min. | 500 MB | | Team | 4 USD/Nutzer | 3.000 Min. | 2 GB | | Enterprise | 21 USD/Nutzer | 50.000 Min. | 50 GB |

Zusaetzliche Minuten: Linux 0,008 USD/Min., Windows 0,016 USD/Min., macOS 0,08 USD/Min.

Wichtig: Open-Source-Projekte auf GitHub erhalten unbegrenzte kostenlose Minuten auf oeffentlichen Repositories.

Docker-Integration#

Alle drei Tools integrieren sich gut mit Docker, aber auf unterschiedliche Weise.

Jenkins + Docker#

Jenkins kann Pipelines in Docker-Containern ausfuehren (Docker-Agent), Images bauen und in Registries pushen. Es erfordert installiertes Docker auf dem Agent und das Docker-Pipeline-Plugin.

// Jenkins - Multi-Stage Docker-Image bauen
pipeline {
    agent any
    stages {
        stage('Build & Push') {
            steps {
                script {
                    def image = docker.build("myapp:${env.BUILD_NUMBER}")
                    docker.withRegistry('https://registry.example.com', 'registry-credentials') {
                        image.push()
                        image.push('latest')
                    }
                }
            }
        }
    }
}

GitLab CI/CD + Docker#

GitLab bietet native Docker-Integration, einschliesslich einer integrierten Container Registry. Jedes Repository erhaelt seine eigene Image-Registry. Services ermoeglichen das Ausfuehren zusaetzlicher Container (z.B. Datenbanken) waehrend des Builds.

# GitLab CI - Docker-Image bauen und pushen
build-image:
  image: docker:24.0
  services:
    - docker:24.0-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

GitHub Actions + Docker#

GitHub Actions bietet vorinstalliertes Docker auf Linux-Runnern. Dedizierte Actions vereinfachen das Bauen und Pushen von Images. GitHub Packages (ghcr.io) dient als Container-Registry.

# GitHub Actions - Docker-Image bauen und pushen
build-image:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    - uses: docker/build-push-action@v5
      with:
        context: .
        push: true
        tags: |
          ghcr.io/${{ github.repository }}:${{ github.sha }}
          ghcr.io/${{ github.repository }}:latest
        cache-from: type=gha
        cache-to: type=gha,mode=max

Parallelisierung und Matrix Builds#

Paralleles Ausfuehren von Aufgaben verkuerzt die Pipeline-Laufzeit drastisch. Matrix Builds ermoeglichen das gleichzeitige Testen ueber mehrere Versionen hinweg.

Jenkins - parallel und matrix#

// Jenkins - Matrix Build
pipeline {
    agent none
    stages {
        stage('Test Matrix') {
            matrix {
                axes {
                    axis {
                        name 'NODE_VERSION'
                        values '18', '20', '22'
                    }
                    axis {
                        name 'OS'
                        values 'linux', 'windows'
                    }
                }
                stages {
                    stage('Test') {
                        agent {
                            label "${OS}"
                        }
                        steps {
                            sh "nvm use ${NODE_VERSION} && npm test"
                        }
                    }
                }
            }
        }
    }
}

GitLab CI/CD - parallel matrix#

# GitLab - Matrix Build
test:
  stage: test
  image: node:${NODE_VERSION}-alpine
  parallel:
    matrix:
      - NODE_VERSION: ['18', '20', '22']
        DATABASE: ['postgres', 'mysql']
  script:
    - npm ci
    - npm test
  services:
    - name: ${DATABASE}:latest

GitHub Actions - strategy matrix#

# GitHub Actions - Matrix Build
test:
  runs-on: ${{ matrix.os }}
  strategy:
    fail-fast: false
    matrix:
      os: [ubuntu-latest, windows-latest, macos-latest]
      node-version: [18, 20, 22]
      exclude:
        - os: macos-latest
          node-version: 18
      include:
        - os: ubuntu-latest
          node-version: 22
          coverage: true
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test
    - if: matrix.coverage
      run: npm run test:coverage

GitHub Actions bietet die intuitivste Matrix-Build-Syntax mit integrierter Unterstuetzung fuer include, exclude und fail-fast.

Secrets-Management#

Das sichere Speichern und Verwenden geheimer Werte (API-Schluessel, Passwoerter, Zertifikate) ist ein kritischer Aspekt jeder CI/CD-Pipeline.

Jenkins - Credentials Store#

Jenkins speichert Secrets in einem internen Credential Store, der Werte auf der Festplatte mit einem instanzspezifischen Schluessel verschluesselt. Es werden verschiedene Typen unterstuetzt: Passwoerter, Tokens, SSH-Zertifikate, Dateien und X.509-Zertifikate. Die Integration mit externen Anbietern (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) erfordert zusaetzliche Plugins.

// Jenkins - Verschiedene Secret-Typen verwenden
pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([
                    string(credentialsId: 'api-token', variable: 'API_TOKEN'),
                    usernamePassword(credentialsId: 'db-creds', usernameVariable: 'DB_USER', passwordVariable: 'DB_PASS'),
                    file(credentialsId: 'kubeconfig', variable: 'KUBECONFIG')
                ]) {
                    sh './deploy.sh'
                }
            }
        }
    }
}

GitLab CI/CD - CI/CD-Variablen#

GitLab bietet CI/CD-Variablen auf Projekt-, Gruppen- oder Instanzebene. Variablen koennen als "masked" (in Logs versteckt) und "protected" (nur auf geschuetzten Branches verfuegbar) markiert werden. Die HashiCorp-Vault-Integration ist im Premium-Plan integriert.

# GitLab - Geschuetzte Variablen und Vault verwenden
deploy:
  script:
    - echo "$KUBE_CONFIG" | base64 -d > kubeconfig
    - kubectl --kubeconfig=kubeconfig apply -f k8s/
  variables:
    KUBE_CONFIG: $KUBE_CONFIG  # protected + masked Variable
  secrets:
    DATABASE_PASSWORD:
      vault:
        engine:
          name: kv-v2
          path: secret
        path: production/db
        field: password
  only:
    - main

GitHub Actions - GitHub Secrets#

GitHub Secrets sind auf Repository-, Environment- und Organisationsebene verfuegbar. Werte werden mit libsodium verschluesselt und automatisch in Logs maskiert. Environments bieten zusaetzliche Kontrolle: erforderliche Reviewer-Genehmigungen, Wartezeiten (Wait Timer) und Branch-Einschraenkungen.

# GitHub Actions - Secrets und Environments
deploy:
  runs-on: ubuntu-latest
  environment:
    name: production
    url: https://example.com
  steps:
    - uses: actions/checkout@v4
    - uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - run: az webapp deploy --name myapp --src-path dist/
    - uses: actions/github-script@v7
      with:
        script: |
          await github.rest.repos.createDeploymentStatus({
            owner: context.repo.owner,
            repo: context.repo.repo,
            deployment_id: context.payload.deployment.id,
            state: 'success'
          });

Vergleichstabelle#

| Kriterium | Jenkins | GitLab CI/CD | GitHub Actions | |-----------|:-------:|:------------:|:--------------:| | Hosting-Modell | Self-hosted | Cloud + Self-hosted | Cloud + Self-hosted | | Pipeline-Syntax | Groovy (Jenkinsfile) | YAML (.gitlab-ci.yml) | YAML (Workflow) | | Lernkurve | Steil | Moderat | Sanft | | Zeit bis zur ersten Pipeline | 1-4 Std. | 5-15 Min. (SaaS) | 2-5 Min. | | Oekosystem | 1.800+ Plugins | Integriert + Vorlagen | Marketplace (tausende Actions) | | Docker | Sehr gut (Plugin) | Hervorragend (nativ) | Hervorragend (nativ) | | Container Registry | Keine (extern) | Integriert | GitHub Packages (ghcr.io) | | Matrix Builds | Ja (seit Jenkins 2.x) | Ja (parallel:matrix) | Ja (strategy:matrix) | | Secrets | Credential Store + Plugins | CI/CD-Variablen + Vault | GitHub Secrets + Environments | | Artefakte | archiveArtifacts | Integriert (expire_in) | actions/upload-artifact | | Cache | Plugins (Job Cacher) | Integriert (key/paths) | actions/cache | | Kostenlose Minuten | Unbegrenzt (self-hosted) | 400 Min./Monat | 2.000 Min./Monat | | Security Scanning | Plugins | Integriert (Ultimate) | Marketplace + Dependabot | | Environments | Plugins | Integriert | Integriert | | Community-Support | Riesig (Legacy) | Gross und wachsend | Sehr gross |

Wann welches Tool waehlen?#

Waehlen Sie Jenkins, wenn:#

Sie volle Kontrolle ueber die CI/CD-Infrastruktur benoetigen und nicht von einem Cloud-Anbieter abhaengig sein wollen
Sie in einer Air-Gapped-Umgebung arbeiten oder strenge Sicherheits- und Compliance-Anforderungen haben
Sie einen komplexen, nicht-standardmaessigen Build-Prozess haben, der maximale Groovy-Flexibilitaet erfordert
Ihr Team bestehende Jenkins-Erfahrung und eine funktionierende Infrastruktur hat
Sie Integration mit exotischen Tools benoetigen, fuer die Jenkins-Plugins existieren
Infrastruktur-Budget vorhanden ist, Sie aber Per-User-Gebuehren vermeiden moechten

Waehlen Sie GitLab CI/CD, wenn:#

Sie eine integrierte DevOps-Plattform suchen (Code + CI/CD + Container Registry + Monitoring + Security in einem)
Sie integrierte Sicherheitstools benoetigen (SAST, DAST, Dependency Scanning, Container Scanning)
Sie Flexibilitaet zwischen Cloud und Self-Hosted mit Migrationsmoeglichkeiten wuenschen
Sie mehrere Projekte und Gruppen verwalten und hierarchisches Management benoetigen
Sie Auto DevOps schaetzen - automatische Spracherkennung und Pipeline-Konfiguration
Sie eine integrierte Container Registry und Package Registry benoetigen

Waehlen Sie GitHub Actions, wenn:#

Ihr Code bereits auf GitHub liegt und Sie die einfachstmoegliche CI/CD-Integration wuenschen
Sie einen schnellen Einstieg ohne Infrastruktur-Konfiguration benoetigen - eine funktionierende Pipeline in 5 Minuten
Sie ein reichhaltiges Oekosystem fertiger Actions aus dem Marketplace nutzen moechten
Sie Open-Source-Projekte entwickeln - unbegrenzte kostenlose Minuten auf oeffentlichen Repositories
Sie Matrix Builds benoetigen, die gleichzeitig auf mehreren Betriebssystemen testen
Sie event-gesteuerte Automatisierung schaetzen - nicht nur CI/CD, sondern auch Automatisierung von Issues, Releases und PRs

Migration zwischen Tools#

Wenn Sie eine Migration von einem Tool zu einem anderen in Betracht ziehen, stehen folgende Ressourcen zur Verfuegung:

Jenkins zu GitHub Actions: GitHub bietet den offiziellen Actions Importer zur Konvertierung von Jenkinsfiles in Workflow-YAML
Jenkins zu GitLab CI: GitLab stellt einen Jenkins-CI-Migrationsleitfaden bereit
GitLab zu GitHub Actions: Erfordert manuelle Konvertierung, aber die YAML-Syntax ist aehnlich
GitHub Actions zu GitLab CI: Ebenfalls manuelle Konvertierung unter Verwendung der GitLab-Dokumentation

In jedem Fall erfordert die Migration auch die Uebertragung von Secrets, Umgebungskonfigurationen und die Anpassung von Integrationen.

Fazit#

Es gibt kein einzelnes "bestes" CI/CD-Tool - die Wahl haengt vom Kontext Ihrer Organisation, dem bestehenden Oekosystem und den spezifischen Projektanforderungen ab.

Jenkins ist eine solide Wahl fuer Unternehmen, die volle Kontrolle ueber ihre CI/CD-Infrastruktur benoetigen. Seine Flexibilitaet und sein Plugin-Oekosystem sind unerreicht, gehen aber mit hoeheren Wartungskosten und einer steilen Lernkurve einher.

GitLab CI/CD ist die beste Wahl fuer Organisationen, die eine integrierte "All-in-One"-DevOps-Plattform suchen. Wenn Sie CI/CD, Container Registry, Security Scanning und Projektmanagement in einem einzigen Tool benoetigen, ist GitLab die offensichtliche Wahl.

GitHub Actions ist der ideale Einstiegspunkt fuer Teams, die bereits GitHub nutzen. Es bietet die schnellste Zeit von null zur funktionierenden Pipeline, ein hervorragendes Oekosystem fertiger Actions und das grosszuegigste kostenlose Kontingent.

Viele Organisationen verfolgen einen hybriden Ansatz - beispielsweise GitHub Actions fuer CI (Bauen und Testen) in Kombination mit ArgoCD fuer CD (Deployments auf Kubernetes). Der Schluessel liegt darin, das Tool an die Beduerfnisse des Teams anzupassen und nicht umgekehrt.

Brauchen Sie Hilfe bei der CI/CD-Einrichtung?#

Bei MDS Software Solutions Group sind wir auf die Konzeption und Implementierung von CI/CD-Pipelines spezialisiert, die auf die Beduerfnisse Ihres Teams zugeschnitten sind. Wir haben Erfahrung mit Jenkins, GitLab CI/CD, GitHub Actions sowie Tools wie ArgoCD, Terraform und Kubernetes.

Ob Sie eine Pipeline von Grund auf aufbauen, von Jenkins zu GitHub Actions migrieren oder bestehende Prozesse optimieren muessen - unser Team hilft Ihnen, Software schneller und sicherer auszuliefern.

Kontaktieren Sie uns und sprechen wir ueber die Automatisierung Ihres Software-Delivery-Prozesses. Die erste Beratung ist kostenlos.