DSGVO und IT-Systeme — Technische Vorbereitung auf die Verordnung

Manuelles Deployment am Freitag um 17:00 Uhr — jeder kennt es, niemand will es wiederholen. Eine automatisierte CI/CD-Pipeline eliminiert menschliche Fehler, verkürzt die Feedback-Schleife und ermöglicht es, dutzende Male am Tag mit Zuversicht zu deployen. Wir zeigen, wie man eine aufbaut.

Anatomie einer modernen CI/CD-Pipeline¶

Eine Pipeline ist nicht nur „Build und Deploy”. Eine qualitativ hochwertige Pipeline hat klar definierte Stages, bei denen jede Phase bestanden werden muss, bevor die nächste startet:

• Commit Stage — Lint, Unit-Tests, Compile (< 5 Min.)
• Build Stage — Docker Image Build, Artifact Packaging
• Security Stage — SAST, Dependency Scanning, Container Scanning
• Test Stage — Integrationstests, API-Tests, E2E-Tests
• Staging Deploy — automatisches Deployment auf die Staging-Umgebung
• Production Deploy — manuelles Approval + automatisierter Rollout

GitLab CI — Pipeline as Code¶

GitLab CI definiert die Pipeline in einer .gitlab-ci.yml-Datei direkt im Repository. Vorteil: Die Pipeline wird zusammen mit dem Code versioniert.

stages:
  - test
  - build
  - security
  - deploy-staging
  - deploy-prod

unit-tests:
  stage: test
  image: node:10-alpine
  script:
    - npm ci
    - npm run lint
    - npm run test:unit -- --coverage
  artifacts:
    reports:
      junit: coverage/junit.xml
  only:
    - merge_requests
    - master

build-image:
  stage: build
  image: docker:stable
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - master

dependency-scan:
  stage: security
  image: node:10-alpine
  script:
    - npm audit --audit-level=high
  allow_failure: true

deploy-staging:
  stage: deploy-staging
  script:
    - kubectl set image deployment/api api=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - kubectl rollout status deployment/api --timeout=120s
  environment:
    name: staging
  only:
    - master

deploy-production:
  stage: deploy-prod
  script:
    - kubectl set image deployment/api api=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - kubectl rollout status deployment/api --timeout=300s
  environment:
    name: production
  when: manual
  only:
    - master

Jenkins — Der flexible Veteran¶

Jenkins ist im Enterprise-Umfeld nach wie vor dominant. Jenkinsfile (deklarative Pipeline) bringt Pipeline-as-Code auch in die Jenkins-Welt:

pipeline {
    agent { docker { image 'node:10-alpine' } }
    stages {
        stage('Test') {
            steps {
                sh 'npm ci'
                sh 'npm run test:unit'
            }
            post {
                always { junit 'coverage/junit.xml' }
            }
        }
        stage('Build') {
            steps {
                sh "docker build -t api:${env.BUILD_NUMBER} ."
                sh "docker push registry.company.com/api:${env.BUILD_NUMBER}"
            }
        }
        stage('Deploy Staging') {
            steps {
                sh "kubectl set image deployment/api api=registry.company.com/api:${env.BUILD_NUMBER}"
            }
        }
        stage('Deploy Production') {
            input { message 'Deploy to production?' }
            steps {
                sh "kubectl set image deployment/api api=registry.company.com/api:${env.BUILD_NUMBER}"
            }
        }
    }
}

GitLab CI vs Jenkins — Was wählen?¶

• GitLab CI: bessere Developer Experience, integriert mit dem GitLab-Repository, einfachere Konfiguration, Shared Runners kostenlos. Ideal für kleine bis mittlere Teams.
• Jenkins: flexibler, riesiges Plugin-Ökosystem (1500+), besser für komplexe Enterprise-Pipelines mit individuellen Schritten. Erfordert Jenkins-Server-Verwaltung.
• Trend 2018: GitLab CI wächst schnell, Jenkins hält seine Position dank Legacy-Installationen und Enterprise-Adoption.

Security in der Pipeline — Shift Left¶

Sicherheitsprüfungen gehören in die Pipeline, nicht ans Ende des Entwicklungszyklus:

• SAST (Static Application Security Testing) — SonarQube, Bandit (Python), ESLint Security Plugin
• Dependency Scanning — npm audit, OWASP Dependency Check, Snyk
• Container Scanning — Clair, Trivy für Docker Image Scanning
• Secret Detection — git-secrets, truffleHog zur Erkennung commiteter Credentials

Wichtig: Die Security Stage sollte am ersten Tag nicht das Deployment blockieren. Beginnen Sie mit allow_failure: true und verschärfen Sie schrittweise, wenn das Team bestehende Findings behoben hat.

Zero-Downtime Deployment¶

Kubernetes Rolling Update ist die Grundlage, reicht aber nicht aus. Für echtes Zero-Downtime benötigen Sie:

• Readiness Probes — Kubernetes sendet Traffic erst, wenn der Pod bereit ist
• Graceful Shutdown — die Anwendung schließt laufende Requests ab, bevor sie stoppt
• Datenbank-Migrationen — abwärtskompatible Migrationen (Expand-Contract Pattern)
• Feature Flags — Deployment vom Release trennen (LaunchDarkly, Unleash)

Pipeline-Metriken¶

Was man nicht misst, kann man nicht verbessern. Verfolgen Sie:

• Lead Time — Zeit vom Commit bis zum Produktions-Deployment
• Deployment-Frequenz — wie oft pro Tag/Woche Sie deployen
• MTTR — Mean Time to Recovery nach fehlgeschlagenem Deployment
• Change Failure Rate — Prozentsatz der Deployments, die Hotfix/Rollback erfordern

Diese vier Metriken stammen aus der DORA-Forschung (DevOps Research and Assessment) und korrelieren mit der Gesamtleistung der Organisation.

Die Pipeline ist eine Investition, die sich in Wochen auszahlt¶

Der Aufbau einer qualitativ hochwertigen CI/CD-Pipeline dauert 2–5 Tage. Die Rendite kommt sofort — weniger Bugs in der Produktion, schnelleres Feedback für Entwickler, weniger Stress bei Releases. Beginnen Sie einfach (Test + Build + Deploy) und iterieren Sie. Die perfekte Pipeline gibt es nicht, aber jede automatisierte Pipeline ist besser als keine.