CI/CD-Pipeline Interviewfragen 2026: GitHub Actions, GitLab CI und Jenkins im Vergleich

Im Jahr 2026 gehören CI/CD-Pipelines zu den fundamentalen Bestandteilen moderner Softwareentwicklung. Unternehmen setzen dabei vor allem auf drei dominierende Plattformen: GitHub Actions mit seiner nahtlosen Integration in GitHub-Repositories, GitLab CI als integrierte Lösung innerhalb der GitLab-Plattform und Jenkins als etabliertes Open-Source-Tool mit umfangreicher Plugin-Architektur. Technische Interviews für DevOps-Positionen fokussieren sich zunehmend auf praktisches Wissen über diese Systeme. Kandidaten müssen nicht nur theoretische Konzepte beherrschen, sondern auch konkrete Implementierungsdetails, Security-Best-Practices und Performance-Optimierungen kennen. Die folgenden Fragen und Antworten spiegeln die aktuellen Anforderungen der Branche wider und helfen bei der Vorbereitung auf anspruchsvolle Interviewsituationen.

GitHub Actions: Workflow-Orchestrierung und Matrix Builds

GitHub Actions hat sich seit seiner Einführung zum Standard für CI/CD in Open-Source-Projekten entwickelt. Das Modell basiert auf Event-getriebenen Workflows, die durch Git-Events, Zeitpläne oder externe Webhooks ausgelöst werden. Ein typischer Workflow besteht aus Jobs, die parallel oder sequenziell ausgeführt werden können. Jeder Job läuft in einer eigenen VM oder einem Container und kann mehrere Steps enthalten.

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

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

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

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Häufige Interviewfragen zu GitHub Actions konzentrieren sich auf das needs-Keyword für Job-Abhängigkeiten, die strategy.matrix-Syntax für parallele Builds mit unterschiedlichen Parametern und die environment-Funktionalität für geschützte Deployments mit manuellen Approval-Prozessen. Das Caching-Verhalten von actions/setup-node mit dem cache-Parameter optimiert die Build-Zeiten erheblich, indem node_modules zwischen Workflow-Runs wiederverwendet werden.

Ein weiterer kritischer Aspekt sind Reusable Workflows. Organisationen können Workflow-Templates als .github/workflows/shared-*.yml definieren und diese über mehrere Repositories hinweg referenzieren. Dies reduziert Code-Duplikation und vereinfacht Compliance-Anforderungen, da zentrale Sicherheits-Scans oder Deployment-Gates an einer Stelle gepflegt werden können.

Die Execution-Kontexte github, env, secrets und steps enthalten zur Laufzeit Metadaten über den aktuellen Workflow-Run. Die Expression-Syntax ${{ }} erlaubt dynamische Wertberechnung und Conditional-Logik. Ein häufiger Fehler ist die Verwendung von if: ${{ github.ref == 'main' }} statt der korrekten Form if: github.ref == 'refs/heads/main' – die vollständige Ref-Syntax ist erforderlich, da github.ref den kompletten Branch-Pfad zurückgibt.

GitLab CI: Stage-basierte Pipelines und Artifact Management

GitLab CI verfolgt ein Stage-basiertes Modell, bei dem Jobs innerhalb derselben Stage parallel ausgeführt werden, die Stages selbst jedoch sequenziell ablaufen. Dies unterscheidet sich fundamental von GitHub Actions, wo Jobs standardmäßig parallel laufen, außer explizite needs-Abhängigkeiten definiert sind.

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

Das rules-Keyword hat in GitLab CI 14+ das ältere only/except-Modell abgelöst und bietet granulare Kontrolle über Job-Ausführungen basierend auf Branch-Namen, Tags, Merge-Request-Status oder Custom-Variablen. Die Kombination when: manual mit rules ermöglicht Approval-Gates für kritische Deployments. Der Job erscheint im Pipeline-View als manuell auslösbar, blockiert jedoch nicht nachfolgende Stages.

Artifacts in GitLab CI dienen dem Datenaustausch zwischen Jobs verschiedener Stages. Der reports-Block ermöglicht die Integration von Test-Coverage, SAST-Scans oder Dependency-Listen direkt in die GitLab-UI. Die expire_in-Direktive verhindert unbegrenztes Wachstum des Artifact-Storage – ein häufiges Problem bei großen Codebases mit langen Pipeline-Historien.

Das Cache-System unterscheidet sich vom Artifact-System: Caches optimieren Rebuild-Zeiten durch Wiederverwendung von Dependencies wie node_modules, während Artifacts explizit für Job-zu-Job-Kommunikation gedacht sind. Der Cache-Key sollte Branch-spezifisch sein (${CI_COMMIT_REF_SLUG}), um Race-Conditions bei parallelen Pipelines in verschiedenen Branches zu vermeiden.

GitLab CI bietet seit Version 16 DAG (Directed Acyclic Graph) Pipelines über das needs-Keyword, ähnlich wie GitHub Actions. Dies erlaubt Job-Ausführung vor Abschluss der gesamten vorherigen Stage, sofern die direkten Abhängigkeiten erfüllt sind. Diese Hybrid-Strategie kombiniert die Übersichtlichkeit stage-basierter Pipelines mit der Performance-Optimierung durch gezielte Parallelisierung.

Jenkins: Declarative vs. Scripted Pipelines und Plugin-Ökosystem

Jenkins bleibt 2026 relevant, insbesondere in Enterprise-Umgebungen mit komplexen On-Premise-Anforderungen. Die Declarative Pipeline-Syntax hat sich gegenüber der älteren Scripted Pipeline als Best Practice etabliert, da sie strukturierter und fehlerresistenter ist.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

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

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Die agent-Direktive definiert, wo die Pipeline ausgeführt wird. agent any verwendet einen beliebigen verfügbaren Agent, während agent { label 'linux' } auf Agents mit spezifischem Label einschränkt. Für Container-basierte Builds bietet agent { docker 'node:22' } eine isolierte Umgebung ohne permanente Tool-Installation auf dem Jenkins-Server.

Der tools-Block referenziert in Jenkins konfigurierte Tool-Installationen. Dies entkoppelt die Pipeline-Definition von konkreten Pfaden und erlaubt zentrale Verwaltung von Node.js-, Maven- oder JDK-Versionen. Das credentials-Keyword im environment-Block bindet Jenkins-Credentials als Umgebungsvariablen ein, ohne Secrets im Jenkinsfile zu exponieren.

Parallel Execution in Jenkins erfolgt über verschachtelte parallel-Blöcke innerhalb einer Stage. Anders als Matrix Builds in GitHub Actions oder GitLab CI erfordert dies explizite Stage-Definitionen für jeden parallelen Zweig. Die post-Direktive auf Stage- oder Pipeline-Ebene definiert Cleanup- oder Notification-Logik, die unabhängig vom Build-Status ausgeführt wird (always, success, failure, unstable, changed).

Das Jenkins Plugin-Ökosystem mit über 1.800 Plugins bietet Integrationen für nahezu jedes Tool der DevOps-Landschaft. Kritische Plugins wie Blue Ocean für modernere UI, Pipeline Stage View für Visualisierung und Configuration as Code (JCasC) für deklarative Jenkins-Konfiguration werden in Interviews häufig thematisiert. Die Plugin-Verwaltung erfordert jedoch kontinuierliche Wartung – veraltete oder inkompatible Plugins sind eine häufige Fehlerquelle.

Security Best Practices: Secret Management und Supply Chain Attacks

Security-Fragen dominieren 2026 die CI/CD-Interviews. Die Kompromittierung von Build-Pipelines durch Supply Chain Attacks hat seit den SolarWinds- und CodeCov-Incidents höchste Priorität.

# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

SHA-Pinning von Actions in GitHub Workflows verhindert, dass ein kompromittierter Tag-Name auf bösartigen Code umgeleitet wird. Tools wie Dependabot erstellen automatisch Pull Requests, wenn neue Versionen mit Security-Fixes verfügbar sind. Die Kombination aus SHA-Pinning und automatischen Updates balanciert Security und Wartbarkeit.

Secret Management erfordert unterschiedliche Strategien je nach Plattform. GitHub Actions nutzt Repository-, Organization- und Environment-Secrets mit unterschiedlichen Scope-Ebenen. Environment-Secrets ermöglichen zusätzlich Approval-Workflows und Branch-Restrictions. GitLab CI unterscheidet zwischen normalen und Protected Variables – letztere sind nur in Protected Branches verfügbar. Jenkins verwendet das Credentials Plugin mit verschiedenen Credential-Typen (Username/Password, Secret Text, SSH Keys, Certificates).

OIDC (OpenID Connect) hat sich als Best Practice für Cloud-Deployments etabliert. Statt statischer Access Keys authentifiziert sich die Pipeline über kurzlebige Tokens direkt beim Cloud Provider. GitHub Actions unterstützt OIDC für AWS, Azure und GCP nativ. GitLab CI bietet ID Tokens über $CI_JOB_JWT. Jenkins erfordert dedizierte Plugins für OIDC-Integration.

Performance-Optimierung: Caching-Strategien und Matrix Efficiency

Performance-Fragen bewerten das Verständnis für Pipeline-Kosten und Optimierungspotenziale. Eine 20-minütige Pipeline, die zehnmal täglich läuft, verbraucht erhebliche Runner-Minuten und blockiert Entwickler-Feedback-Loops.

Caching ist die effektivste Optimierung. GitHub Actions actions/cache speichert Dependencies zwischen Runs. Der Cache-Key sollte einen Hash der Dependency-Datei enthalten (hashFiles('package-lock.json')) und automatisch invalidiert werden, wenn sich Dependencies ändern. Der restore-keys-Parameter ermöglicht Fallback auf teilweise Matches, wenn kein exakter Key existiert.

GitLab CI Cache mit key: files: ['package-lock.json'] implementiert ähnliche Logik. Die policy: pull-push (default) vs. policy: pull Unterscheidung verhindert Race-Conditions, wenn mehrere Jobs denselben Cache nutzen – nur ein Job sollte den Cache updaten, andere nur lesen.

Jenkins nutzt Workspace-Reuse für sequenzielle Stages standardmäßig. Für parallele Jobs oder Multi-Branch-Pipelines hilft das Stash/Unstash-Feature, Artifacts zwischen Agents zu transferieren. External Caching über das Job Cacher Plugin oder Artifact Manager on S3 Plugin skaliert besser bei großen Codebases.

Matrix Builds erhöhen die Parallelisierung, generieren jedoch auch Kosten. Eine Matrix mit 5 Node-Versionen x 3 OS-Varianten = 15 parallele Jobs. Interviewfragen zielen darauf ab, ob Kandidaten Matrix-Dimensions sinnvoll begrenzen können. GitHub Actions strategy.matrix.exclude und include erlauben selektive Kombinationen.

Vergleich und Toolauswahl: GitHub Actions vs. GitLab CI vs. Jenkins

Interview-Panels erwarten begründete Empfehlungen basierend auf organisatorischen Anforderungen. Die folgende Tabelle fasst technische Unterschiede zusammen:

| Merkmal | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | Konfigurationsdatei | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | Ausführungsmodell | Job-basiert (standardmäßig parallel) | Stage-basiert (sequenzielle Stages) | Stage-basiert (flexibel) | | Runner-Hosting | GitHub-hosted + Self-hosted | GitLab.com Shared + Self-hosted | Nur Self-hosted | | Secret-Verwaltung | Repository/Org/Environment Secrets | CI/CD-Variablen (geschützt) | Credentials Plugin | | Matrix Builds | strategy.matrix | parallel:matrix | matrix (Plugin) | | Manuelle Gates | environment + Required Reviewers | when: manual | input-Direktive | | Marketplace | 20.000+ Actions im Marketplace | CI/CD Components Catalog | 1.800+ Plugins | | KI-Funktionen | Copilot for Actions (Preview) | Duo CI Expert Agent (Beta) | Community Plugins | | Preisgestaltung | Kostenlos für öffentliche Repos, minutenbasiert für private | 400 CI/CD-Minuten kostenlos, dann gestaffelt | Kostenlos (Open Source), selbst verwaltet |

GitHub Actions eignet sich optimal für Open-Source-Projekte und Teams, die bereits GitHub für Code-Hosting nutzen. GitLab CI punktet mit der All-in-One-Plattform aus Repository, CI/CD, Container Registry, Security-Scanning und Incident-Management. Jenkins bleibt relevant für Legacy-Systeme, strenge Compliance-Anforderungen oder komplexe On-Premise-Infrastrukturen ohne Cloud-Anbindung.

Hybrid-Ansätze kombinieren Plattformen strategisch: GitHub Actions für schnelles Feedback bei Pull Requests, Jenkins für komplexe Deployments mit spezifischen Compliance-Anforderungen. Interview-Kandidaten sollten solche Architekturen als pragmatische Lösungen diskutieren können, statt dogmatisch eine Plattform zu favorisieren.

Monitoring und Observability: Pipeline-Metriken und Incident Response

Production-Ready CI/CD umfasst Monitoring und Alerting. Build Success Rate und Mean Time to Recovery (MTTR) sind Key Metrics. GitHub Actions bietet Workflow Insights mit Erfolgsraten und durchschnittlicher Laufzeit. GitLab CI Analytics zeigt Deployment Frequency, Lead Time und Change Failure Rate – die vier DORA Metrics. Jenkins Prometheus Metrics Plugin exportiert Build-Statistiken für Grafana-Dashboards.

Flaky Tests destabilisieren Pipelines. GitHub Actions erlaubt Re-Run failed jobs statt des gesamten Workflows. GitLab CI retry: 2 wiederholt fehlgeschlagene Jobs automatisch. Jenkins bietet das Flaky Test Handler Plugin für statistische Auswertung intermittierender Failures. Kandidaten sollten argumentieren können, dass automatisches Retry Symptome behandelt, aber Root Cause Analysis erforderlich bleibt.

Notification-Strategien balancieren Visibility und Alert Fatigue. GitHub Actions workflow_run Webhook zu Slack bei Production-Deployments ist sinnvoll. Notifications bei jedem Failed Test-Run überlastet Channels. GitLab CI Pipeline Schedules mit E-Mail-Benachrichtigungen nur bei Status-Änderung reduziert Rauschen. Jenkins Email-ext Plugin mit Groovy-Templates ermöglicht kontext-spezifische Nachrichten.

Audit Logs protokollieren, wer welche Pipelines triggerte, Secrets änderte oder Production-Deployments genehmigte. GitHub Audit Log API ermöglicht Security-Analysen und Compliance-Reports. GitLab Audit Events tracken alle sicherheitsrelevanten Änderungen. Jenkins Audit Trail Plugin loggt Konfigurationsänderungen mit Timestamp und User.

Die Vorbereitung auf CI/CD-Interviews gelingt am besten durch praktische Übung mit den CI/CD-Grundlagen und plattformspezifischen Modulen zu GitHub Actions, GitLab CI und Jenkins. Der umfassende Leitfaden zu DevOps-Interviewfragen deckt weitere Themengebiete jenseits von CI/CD ab.

Fazit

• GitHub Actions dominiert das Open-Source-Ökosystem mit nahtloser GitHub-Integration, umfangreichem Marketplace und kommenden Features wie Parallel Steps, erfordert jedoch konsequentes SHA-Pinning gegen Supply-Chain-Risiken
• GitLab CI bietet die engste Integration zwischen CI/CD und Security-Scanning mit SLSA-Attestierung für Components und feingranularen Job-Token-Berechtigungen seit Version 18.3
• Jenkins bleibt die flexibelste Option für Organisationen mit voller Infrastrukturkontrolle, erfordert seit Januar 2026 jedoch Java 21 und bringt einen höheren Wartungsaufwand mit sich
• Secret Management ist das am häufigsten geprüfte Sicherheitsthema über alle drei Plattformen hinweg: Kenntnisse zu Scoped Secrets, Protected Variables und Credential-Rotation-Strategien sind unverzichtbar
• Pipeline-Optimierung durch Caching, Parallelisierung und bedingte Ausführung gilt universell und signalisiert Interviewern praktische Produktionserfahrung
• Kandidaten sollten mindestens eine funktionsfähige Pipeline-Konfiguration pro Plattform vorbereiten und sich auf praxisnahe Muster statt auf Spielzeug-Beispiele konzentrieren