Was ist CI/CD und warum brauchst du es?

Continuous Integration / Continuous Deployment (CI/CD) bedeutet: Jede Code-Änderung wird automatisch getestet, gebaut und deployed. Kein manuelles FTP-Upload, kein SSH ins Server-Tippen, kein "vergessen zu deployen".

Für typoniels.dev nutze ich GitLab CI/CD. Das Ergebnis: Ich pushe Code, trinke Kaffee, und 3 Minuten später ist die Änderung live.

Grundstruktur einer .gitlab-ci.yml

stages:
  - build
  - deploy

build-image:
  stage: build
  image: docker:24
  services:
    - docker:dind
  script:
    - docker build -t registry.typoniels.de/app:$CI_COMMIT_SHA .
    - docker push registry.typoniels.de/app:$CI_COMMIT_SHA
  only:
    - main

deploy-production:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/app app=registry.typoniels.de/app:$CI_COMMIT_SHA
  only:
    - main

Die wichtigsten Konzepte erklärt

Stages

Stages laufen nacheinander ab. Erst build, dann deploy. Schlägt build fehl, wird deploy gar nicht erst gestartet.

Jobs

Jobs innerhalb einer Stage laufen parallel. Ich baue z.B. Frontend und Backend gleichzeitig – das spart Zeit.

Variables und Secrets

Niemals Zugangsdaten in die .gitlab-ci.yml schreiben! Alles in CI/CD Variables (Project Settings → CI/CD → Variables). Mit $VARIABLE_NAME im Script verwenden.

Mein Workflow für typoniels.dev

  1. Feature Branch → Push → Automatischer Build-Test
  2. Merge Request → Reviewer prüft, Pipeline muss grün sein
  3. Merge nach main → Build + Push Docker Image
  4. Deploy auf Kubernetes → Rolling Update, Zero Downtime

Kubernetes Rolling Updates

Das ist das Schöne an Kubernetes: kubectl set image rollt das neue Image Schritt für Schritt aus. Falls etwas schiefgeht, ist ein kubectl rollout undo in Sekunden ausgeführt.

Häufige Fehler und wie ich sie behoben habe

Problem 1: Langsame Builds Lösung: Docker Layer Caching aktivieren. In GitLab mit --cache-from Flag beim docker build.

Problem 2: Secrets in Logs geleakt Lösung: GitLab maskiert automatisch Variablen die als "Masked" markiert sind. Immer aktivieren!

Problem 3: Deploy schlägt fehl, alte Version läuft noch Lösung: Health Checks in Kubernetes (readinessProbe) stellen sicher, dass nur funktionierende Pods Traffic erhalten.

Fazit

GitLab CI/CD ist für Self-Hosted-Projekte meine erste Empfehlung. Die kostenlose Community Edition reicht für die meisten Projekte aus, die Integration mit der GitLab Container Registry ist nahtlos, und die .gitlab-ci.yml ist deutlich einfacher als GitHub Actions für komplexere Workflows.

Wer GitLab bereits nutzt, sollte den Schritt zur CI/CD-Pipeline jetzt machen – der Aufwand ist gering, der Gewinn enorm.