[{"data":1,"prerenderedAt":790},["ShallowReactive",2],{"/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab":3,"navigation-de-de":44,"banner-de-de":446,"footer-de-de":456,"blog-post-authors-de-de-Benjamin Skierlak|James Wormwell":661,"blog-related-posts-de-de-from-code-to-production-a-guide-to-continuous-deployment-with-gitlab":687,"blog-promotions-de-de":726,"next-steps-de-de":780},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":30,"isFeatured":13,"meta":31,"navigation":32,"path":33,"publishedDate":22,"seo":34,"stem":39,"tagSlugs":40,"__hash__":43},"blogPosts/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab",[7,8],"benjamin-skierlak","james-wormwell",null,"product",{"slug":12,"featured":13,"template":14},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",false,"BlogPost",{"heroImage":16,"body":17,"authors":18,"updatedDate":21,"date":22,"title":23,"tags":24,"description":29,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","Die kontinuierliche Bereitstellung ist eine bahnbrechende Praxis, die es Teams ermöglicht, schneller und mit höherem Vertrauen Werte zu schaffen. Das Eintauchen in erweiterte Bereitstellungs-Workflows – wie GitOps, Container-Orchestrierung mit Kubernetes oder dynamische Umgebungen – kann jedoch für Teams, die gerade erst anfangen, einschüchternd sein.\n\nGitLab setzt sich dafür ein, die Bereitstellung nahtlos und skalierbar zu gestalten. Indem wir es den Teams ermöglichen, sich auf die Grundlagen zu konzentrieren, befähigen wir sie, eine starke Basis zu schaffen, die das Wachstum komplexerer Strategien im Laufe der Zeit unterstützt. Dieser Leitfaden enthält wichtige Schritte, um mit der Implementierung der kontinuierlichen Bereitstellung mit GitLab zu beginnen und die Grundlage für deinen langfristigen Erfolg zu schaffen.\n\n## Inhaltsverzeichnis\n\n* [Beginne mit einem Workflow-Plan](#beginne-mit-einem-workflow-plan)\n\n  * [Artefakt-Management-Strategie](#artefakt-management-strategie)\n\n    * [Artefakte und Versionsstrategien](#artefakte-und-versionsstrategien)\n    * [Artefaktaufbewahrung erstellen](#artefaktaufbewahrung-erstellen)\n    * [Registrierungszugriff und Authentifizierung](#registrierungszugriff-und-authentifizierung)\n  * [Umgebungsstrategie](#umgebungsstrategie)\n  * [Bereitstellungsziele](#bereitstellungsziele)\n* [Deine CD-Pipeline implementieren](#deine-cd-pipeline-implementieren)\n\n  * [Ein Schritt-für-Schritt-Beispiel](#ein-schritt-für-schritt-beispiel)\n\n    * [Voraussetzungen](#voraussetzungen)\n  * [Best Practices](#best-practices)\n* [Skaliere deine Bereitstellungsstrategie](#skaliere-deine-bereitstellungsstrategie)\n\n  * [Erweiterte Sicherheitsmaßnahmen](#erweiterte-sicherheitsmaßnahmen)\n  * [Progressive Bereitstellungsstrategien](#progressive-bereitstellungsstrategien)\n  * [Überwachung und Optimierung](#überwachung-und-optimierung)\n* [Warum GitLab](#warum-gitlab)\n* [Noch heute starten](#noch-heute-starten)\n\n## Beginne mit einem Workflow-Plan\n\nBevor du dich mit der technischen Implementierung befasst, nimm dir Zeit, um deinen Bereitstellungs-Workflow zu planen. Der Erfolg liegt in der sorgfältigen Planung und dem methodischen Vorgehen.\n\n### Artefakt-Management-Strategie\n\nIm Zusammenhang mit der kontinuierlichen Bereitstellung sind Artefakte die Paket-Ausgaben deines Build-Prozesses, die gespeichert, als Versionen verwaltet und bereitgestellt werden müssen. Darunter fallen:\n\n* Container-Images für deine Anwendungen\n* Pakete\n* kompilierte Binärdateien oder ausführbare Dateien\n* Bibliotheken\n* Konfigurationsdateien\n* Dokumentationspakete\n* andere Artefakte\n\nJede Art von Artefakt spielt eine bestimmte Rolle in deinem Bereitstellungsprozess. Zum Beispiel könnte eine typische Webanwendung Folgendes generieren:\n\n* ein Container-Image für den Backend-Service\n* ein ZIP-Archiv mit kompilierten Frontend-Assets\n* SQL-Dateien für Datenbankänderungen\n* umweltspezifische Konfigurationsdateien\n\nDie effektive Verwaltung dieser Artefakte ist für erfolgreiche Bereitstellungen von entscheidender Bedeutung. Hier erfährst du, wie du das Artefakt-Management angehen kannst.\n\n#### Artefakte und Versionsstrategien\n\nEine Best Practice, um mit einer sauberen Struktur zu beginnen, besteht darin, eine klare Versionsstrategie für deine Artefakte festzulegen. Bei der Erstellung von Releases gilt:\n\n* Verwende eine semantische Versionsverwaltung (major.minor.patch) für Release-Tags\n\n  * Beispiel: `myapp:1.2.3` für ein stabiles Release\n  * Wichtige Versionsänderungen (2.0.0) für Breaking Changes\n  * Geringfügige Versionsänderungen (1.3.0) für neue Funktionen\n  * Patch-Versionsänderungen (1.2.4) für Fehlerbehebungen\n* Pflege einen „neuesten“ Tag für die neueste stabile Version\n\n  * Beispiel: `myapp:latest` für automatisierte Bereitstellungen\n* Beziehe Commit-SHA für präzises Versions-Tracking ein\n\n  * Beispiel: `myapp:1.2.3-abc123f` zum Debuggen\n* Berücksichtige Branch-basierte Tags für Entwicklungsumgebungen\n\n  * Beispiel: `myapp: feature-user-auth` für Funktionstests\n\n#### Artefaktaufbewahrung erstellen\n\nImplementiere definierte Aufbewahrungsregeln:\n\n* Lege explizite Ablaufzeitrahmen für temporäre Artefakte fest\n* Definiere, welche Artefakte dauerhaft aufbewahrt werden müssen\n* Konfiguriere Bereinigungsrichtlinien zur Verwaltung des Speichers\n\n#### Registrierungszugriff und Authentifizierung\n\nSchütze deine Artefakte mit den richtigen Zugangskontrollen:\n\n* Implementiere persönliche Zugriffstoken für den Entwicklerzugriff\n* Konfiguriere CI/CD-Variablen für die Pipeline-Authentifizierung\n* Richte ordnungsgemäße Zugangsumfänge ein\n\n### Umgebungsstrategie\n\nBetrachte deine Umgebungen frühzeitig, da sie deine gesamte Bereitstellungspipeline prägen:\n\n* Konfigurationen der Entwicklungs-, Staging- und Produktionsumgebung\n* Umgebungsspezifische Variablen und Geheimnisse\n* Zugangskontrollen und Schutzregeln\n* Ansatz zur Nachverfolgung und Überwachung der Bereitstellung\n\n### Bereitstellungsziele\n\nSei dir bewusst, wo und wie du bereitstellen wirst. Diese Entscheidungen sind wichtig und die jeweiligen Vor- und Nachteile sollten berücksichtigt werden:\n\n* Infrastrukturanforderungen (VMs, Container, Cloud-Services)\n* Netzwerkzugriff und Sicherheitskonfigurationen\n* Authentifizierungsmechanismen (SSH-Schlüssel, Zugriffstoken)\n* Überlegungen zur Ressourcenzuweisung und Skalierung\n\nNachdem wir unsere Strategie definiert und grundlegende Entscheidungen getroffen haben, können wir diese Pläne jetzt in eine funktionierende Pipeline umsetzen. Wir werden ein praktisches Beispiel erstellen, das diese Konzepte demonstriert, beginnend mit einer einfachen Anwendung und dem schrittweisen Hinzufügen von Bereitstellungsfunktionen.\n\n## Deine CD-Pipeline implementieren\n\n### Ein Schritt-für-Schritt-Beispiel\n\nSehen wir uns nun die Implementierung einer grundlegenden Pipeline für die kontinuierliche Bereitstellung für eine Webanwendung an. Wir werden eine einfache HTML-Anwendung als Beispiel verwenden, aber diese Prinzipien gelten für jede Art von Anwendung. Wir werden unsere Anwendung auch als Docker Image auf einer einfachen virtuellen Maschine bereitstellen. Somit können wir uns auf ein kuratiertes Bild mit minimalen Abhängigkeiten stützen und sicherstellen, dass keine umgebungsspezifischen Anforderungen unbeabsichtigt eingeführt werden. Wenn wir an einer virtuellen Maschine arbeiten, werden wir die nativen Integrationen von GitLab nicht nutzen, sodass wir zunächst an einem einfacheren, aber weniger skalierbaren Setup arbeiten können.\n\n#### Voraussetzungen\n\nIn diesem Beispiel zielen wir darauf ab, eine Anwendung zu containerisieren, die wir auf einer virtuellen Maschine ausführen, die auf einem Cloud-Anbieter gehostet wird. Wir werden diese Anwendung auch lokal auf unserem Computer testen. Diese Liste der Voraussetzungen wird nur für dieses Szenario benötigt.\n\n##### Einrichtung der virtuellen Maschine\n\n* Stelle eine VM in deinem bevorzugten Cloud-Provider (z. B. GCP, AWS, Azure) bereit\n* Konfiguriere die Netzwerkregeln, um den Zugriff auf die Ports 22, 80 und 443 zu ermöglichen\n* Zeichne die öffentliche IP-Adresse des Computers für die Bereitstellung auf\n\n##### SSH-Authentifizierung einrichten:\n\n* Generiere ein öffentliches/privates Schlüsselpaar für die Maschine\n* Gehe in GitLab zu **Einstellungen > CI/CD > Variablen**\n* Erstelle eine Variable mit dem Namen `GITLAB_KEY`\n* Wähle als Typ „Datei“ (für SSH-Authentifizierung erforderlich)\n* Füge den privaten Schlüssel in das Feld „Wert“ ein\n* Definiere eine BENUTZERVARIABLE; dies ist der Benutzer, der sich anmeldet und die Skripte auf deiner VM ausführt\n\n##### Bereitstellungsvariablen konfigurieren\n\n* Erstelle Variablen für deine Bereitstellungsziele:\n\n  * `STAGING_TARGET`: deine Staging-Server-IP/-Domäne\n  * `PRODUCTION_TARGET`: deine Produktionsserver-IP/-Domäne\n\n##### Lokales Entwicklungs-Setup\n\n* Installiere Docker auf deinem lokalen Computer, um Bereitstellungen zu testen\n\n##### GitLab-Container-Registry-Zugriff\n\n* Finde deinen Registry-Pfad:\n\n  * Navigiere zu **Bereitstellen > Container-Registry**\n  * Kopiere den Registry-Pfad (z. B. registry.gitlab.com/group/project)\n* Authentifizierung einrichten:\n\n  * Gehe zu **Einstellungen > Zugriffstoken**\n  * Erstelle ein neues Token mit Registry-Zugriff\n  * Token-Ablauf: max. 1 Jahr\n  * Speichere das Token sicher\n* Lokalen Registry-Zugriff konfigurieren:\n\n```shell\ndocker login registry.gitlab.com\n# Der Benutzername, wenn du einen PAT verwendest, ist gitlab-ci-token\n# Passwort: your-access-token\n```\n\n#### 1. Erstelle deine Anwendung\n\nBeginne mit einer grundlegenden Webanwendung. In unserem Beispiel verwenden wir eine einfache HTML-Seite:\n\n```xml\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Dein Inhalt hier -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Containerisiere deine Anwendung\n\nErstelle ein Dockerfile, um deine Anwendung zu paketieren:\n\n```text\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nDieses Dockerfile:\n\n* Verwendet nginx als Basis-Image für die Bereitstellung von Webinhalten\n* Kopiert deine HTML-Datei an die richtige Stelle in der nginx-Verzeichnisstruktur\n\n#### 3. Richte deine CI/CD-Pipeline ein\n\nErstelle eine `.gitlab-ci.yml`-Datei, um deine Pipeline-Phasen zu definieren:\n\n```yaml\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nSehen wir uns das genauer an:\n\n`TAG_LATEST` besteht aus drei Teilen:\n\n* `$CI_REGISTRY_IMAGE` ist der Pfad zum Container-Registry deines Projekts in GitLab\n\nZum Beispiel: `registry.gitlab.com/your-group/your-project`\n\n* `$CI_COMMIT_REF_NAME` ist der Name deiner Branch oder deines Tags\n\nZum Beispiel, wenn du dich im Haupt-Branch befindest: `/main`, und wenn du dich in einem Feature-Branch befindest: `/feature-login`\n\n* `:latest` ist ein festes Suffix\n\nWenn du dich also im Main-Branch befindest, wird `TAG_LATEST` zu: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` ist fast identisch, aber anstelle von `:latest` verwendet es: `$CI_COMMIT_SHA`, was die Commit-Kennung ist, zum Beispiel: `:abc123def456`.\n\nFür denselben Commit im Haupt-Branch wird `TAG_COMMIT` zu: `registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nDer Grund für beides ist, dass `TAG_LATEST` dir eine einfache Möglichkeit bietet, immer die neueste Version zu erhalten, und `TAG_COMMIT` gibt dir eine bestimmte Version, zu der du bei Bedarf zurückkehren kannst.\n\n#### 4. Im Container-Registry veröffentlichen\n\nFüge den Veröffentlichungsauftrag zu deiner Pipeline hinzu:\n\n```yaml\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nDieser Job:\n\n* verwendet Docker-in-Docker, um Bilder zu entwickeln\n* erstellt zwei getaggte Versionen deines Bildes\n* authentifiziert sich bei der GitLab-Registrierung\n* pusht beide Versionen in das Registry \n\nJetzt, da unsere Bilder sicher im Registry gespeichert sind, können wir uns darauf konzentrieren, sie in unseren Zielumgebungen bereitzustellen. Beginnen wir mit lokalen Tests, um unser Setup zu validieren, bevor wir zu Produktionsbereitstellungen übergehen.\n\n#### 5. In deiner Umgebung bereitstellen\n\nVor der Bereitstellung in der Produktion kannst du einen lokalen Test durchführen. Wir haben unser Image gerade im GitLab-Repository veröffentlicht, das wir lokal abrufen werden. Wenn du dir über den genauen Pfad nicht sicher bist, navigiere zu **Bereitstellen > Container-Registry**. Du solltest ein Symbol sehen, um den Pfad deines Bildes am Ende der Zeile für das Container-Image zu kopieren, das du testen möchtest.\n\n```shell\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nAuf diese Weise solltest du über deinen Webbrowser lokal über deine lokale Host-Adresse auf deine Anwendung zugreifen können.\n\nDu kannst jetzt einen Bereitstellungsjob zu deiner Pipeline hinzufügen:\n\n```yaml\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nDieser Job:\n\n* richtet einen SSH-Zugriff auf dein Bereitstellungsziel ein\n* ruft das neueste Image auf\n* entfernt alle vorhandenen Container\n* stellt die neue Version bereit\n\n#### 6. Bereitstellungen nachverfolgen\n\nAktiviere die Nachverfolgung von Bereitstellungen, indem du die Umgebungskonfiguration hinzufügst:\n\n```yaml\ndeploy:\n  environment:\n    name: production\nurl: https://deine-anwendung-url.com\n```\n\nDadurch wird ein Umgebungsobjekt im Abschnitt **Betreiben > Umgebungen** von GitLab erstellt, das Folgendes bietet:\n\n* Bereitstellungsverlauf\n* aktueller Bereitstellungsstatus\n* schneller Zugriff auf deine Anwendung\n\nWährend eine einzelne Umgebungspipeline ein guter Ausgangspunkt ist, müssen die meisten Teams mehrere Umgebungen verwalten, um ordnungsgemäß zu testen und die Staging-Phase durchzuführen. Lass uns unsere Pipeline erweitern, um dieses realistischere Szenario zu bewältigen.\n\n#### 7. Mehrere Umgebungen einrichten\n\nFür eine robustere Pipeline, konfiguriere Staging- und Produktionsbereitstellungen:\n\n```yaml\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nDieses Setup:\n\n* stellt die Staging-Phase deines Main-Branch bereit\n* verwendet GitLab-Tags, um Produktionsbereitstellungen auszulösen\n* bietet separate Nachverfolgung für jede Umgebung\n\nHier und in unserem nächsten Schritt nutzen wir eine sehr nützliche GitLab-Funktion: Tags. Durch manuelles Erstellen eines Tags im Abschnitt **Code > Tags** wird das `$CI_COMMIT_TAG` erstellt, wodurch wir Jobs entsprechend auslösen können.\n\n#### 8. Automatisierte Versionshinweise erstellen\n\nWir werden die Release-Funktionen von GitLab über unsere CI/CD-Pipeline nutzen. Aktualisiere zuerst deine Phasen in `.gitlab-ci.yml`:\n\n```yaml\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nAls Nächstes fügst du den Release-Job hinzu:\n\n```yaml\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nDu kannst dies verbessern, indem du Links zu deinen Container-Bildern hinzufügst:\n\n```yaml\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nFür die automatische Erzeugung von Versionshinweisen basierend auf Commit-Nachrichten:\n\n```yaml\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release notes for version $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  auto_generate_release_notes: true    # Enables automatic notes\n```\n\nFür aussagekräftige automatisierte Versionshinweise:\n\n* herkömmliche Commits verwenden (feat:, fix:, etc.)\n* Issue-Nummern einschließen (#123)\n* Betreff mit leerer Zeile vom Text trennen\n\nWenn du benutzerdefinierte Versionshinweise mit Bereitstellungsinformationen möchtest:\n\n```text\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nNach der Konfiguration werden Releases automatisch erstellt, wenn du ein Git-Tag erstellst. Du kannst sie in GitLab unter **Bereitstellen > Releases** anzeigen.\n\n#### 9. Alles zusammensetzen\n\nSo sieht unsere finale YAML-Datei aus:\n\n```text\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n       - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nDiese komplette Pipeline:\n\n* veröffentlicht Images im Registry (Main-Branch)\n* stellt das Staging bereit (Main-Branch)\n* erstellt Releases (mit Tags)\n* bietet die Versionsverwaltung von Images mit Release-Tags \n* Stellt die Produktion bereit (für Tags)\n\nHauptvorteile:\n\n* Saubere, reproduzierbare, lokale Entwicklungs- und Testumgebung\n* Klarer Pfad zu Produktionsumgebungen mit Struktur, um Vertrauen in die Bereitstellung aufzubauen\n* Muster zur Wiederherstellung nach unerwarteten Fehlern usw.\n* Bereit, komplexere Bereitstellungsstrategien zu skalieren/zu übernehmen\n\n### Best Practices\n\nWährend der gesamten Implementierung solltest du diese Grundsätze einhalten:\n\n* Dokumentiere alles, von der variablen Nutzung bis hin zu Bereitstellungsverfahren\n* Nutze die integrierten Funktionen von GitLab (Umgebungen, Releases, Registry)\n* Implementiere ordnungsgemäße Zugriffskontrollen und Sicherheitsmaßnahmen\n* Sorge für Ausfälle mit robusten Rollback-Verfahren vor\n* Halte deine Pipeline-Konfigurationen SAUBER (wiederhole dich nicht)\n\n> **12x kürzere Bereitstellungszeit: Dank GitLabs vollständiger Integration lebt Hilti Effizienz**. GitLab bringt vollständige Transparenz, eine umfassende Codeverwaltung und umfangreiche Sicherheitsscans mit, um Hilti neue Softwarefähigkeiten zu ermöglichen. Erfahre, wie Hilti seine Softwareentwicklung revolutioniert hat. **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/hilti/)**\n\n## Skaliere deine Bereitstellungsstrategie\n\nWie geht es weiter? Hier sind einige Aspekte, die du berücksichtigen solltest, wenn deine kontinuierliche Bereitstellungsstrategie ausgereift ist.\n\n### Erweiterte Sicherheitsmaßnahmen\n\nErhöhe die Sicherheit durch:\n\n* Geschützte Umgebungen mit eingeschränktem Zugang\n* Erforderliche Genehmigungen für Produktionseinsätze\n* Integriertes Sicherheitsscannen\n* Automatisierte Schwachstellenbewertungen\n* Branch-Schutzregeln für einsatzbedingte Änderungen\n\n### Progressive Bereitstellungsstrategien\n\nImplementiere erweiterte Bereitstellungsstrategien:\n\n* Feature-Flags für kontrollierte Rollouts\n* Canary-Bereitstellungen zur Risikominderung\n* Blaugrüne Bereitstellungsstrategien\n* A/B-Testfähigkeiten\n* Dynamisches Umgebungsmanagement\n\n### Überwachung und Optimierung\n\nEtabliere robuste Überwachungspraktiken:\n\n* Verfolge Bereitstellungsmetriken nach\n* Richte eine Leistungsüberwachung ein\n* Konfiguriere Bereitstellungswarnungen\n* Richte Bereitstellungs-SLOs ein\n* Regelmäßige Pipeline-Optimierung\n\n## Warum GitLab\n\nDurch die kontinuierlichen Bereitstellungsfunktionen ist GitLab eine herausragende Wahl für moderne Bereitstellungsworkflows. Die Plattform zeichnet sich dadurch aus, dass sie den Weg vom Code bis zur Produktion optimiert und eine integrierte Container-Registrierung, ein Umgebungsmanagement und eine Nachverfolgung der Bereitstellung innerhalb einer einzigen Benutzeroberfläche bietet. Die umgebungsspezifischen Variablen von GitLab, die Approval-Gates für die Bereitstellung und die Rollback-Funktionen bieten die Sicherheit und Kontrolle, die für Produktionsbereitstellungen erforderlich sind, während Funktionen wie Review-Apps und Feature-Flags progressive Bereitstellungsansätze ermöglichen. Als Teil der kompletten DevSecOps-Plattform von GitLab lassen sich diese CD-Funktionen nahtlos in deinen gesamten Software-Lebenszyklus integrieren.\n\n## Noch heute starten\n\nDer Weg zur kontinuierlichen Bereitstellung ist eine Evolution, keine Revolution. Beginne mit den Grundlagen, baue eine solide Grundlage auf und integriere nach und nach erweiterte Funktionen, wenn die Anforderungen deines Teams wachsen. GitLab bietet die Tools und die Flexibilität, um dich in jeder Phase dieser Reise zu unterstützen, von deiner ersten automatisierten Bereitstellung bis hin zu komplexen Bereitstellungspipelines für mehrere Umgebungen.\n\n> Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) an, um noch heute mit der kontinuierlichen Bereitstellung zu beginnen.",[19,20],"Benjamin Skierlak","James Wormwell","2025-05-14","2025-01-28","Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab",[25,26,27,10,28],"CD","CI/CD","features","tutorial","Erfahre, wie du mit dem Aufbau einer robusten Pipeline für die kontinuierliche Bereitstellung in GitLab beginnen kannst. In diesem Artikel findest du Schritt-für-Schritt-Anleitungen, praktische Beispiele und Best Practices.","yml",{},true,"/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"ogTitle":35,"ogImage":16,"ogDescription":29,"ogSiteName":36,"noIndex":13,"ogType":37,"ogUrl":38,"title":35,"canonicalUrls":38,"description":29},"Leitfaden: Kontinuierliche Bereitstellung mit GitLab","https://about.gitlab.com","article","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",[41,42,27,10,28],"cd","cicd","B8_Efp8_WUwcmVhSO7-udI-JhTylW1uAs3mFNQV9Bfs",{"data":45},{"logo":46,"freeTrial":51,"sales":56,"login":61,"items":66,"search":374,"minimal":409,"duo":427,"pricingDeployment":436},{"config":47},{"href":48,"dataGaName":49,"dataGaLocation":50},"/de-de/","gitlab logo","header",{"text":52,"config":53},"Kostenlose Testversion anfordern",{"href":54,"dataGaName":55,"dataGaLocation":50},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":57,"config":58},"Vertrieb kontaktieren",{"href":59,"dataGaName":60,"dataGaLocation":50},"/de-de/sales/","sales",{"text":62,"config":63},"Anmelden",{"href":64,"dataGaName":65,"dataGaLocation":50},"https://gitlab.com/users/sign_in/","sign in",[67,94,189,194,295,355],{"text":68,"config":69,"cards":71},"Plattform",{"dataNavLevelOne":70},"platform",[72,78,86],{"title":68,"description":73,"link":74},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":75,"config":76},"Erkunde unsere Plattform",{"href":77,"dataGaName":70,"dataGaLocation":50},"/de-de/platform/",{"title":79,"description":80,"link":81},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":82,"config":83},"Lerne GitLab Duo kennen",{"href":84,"dataGaName":85,"dataGaLocation":50},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":87,"description":88,"link":89},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":90,"config":91},"Mehr erfahren",{"href":92,"dataGaName":93,"dataGaLocation":50},"/de-de/why-gitlab/","why gitlab",{"text":95,"left":32,"config":96,"link":98,"lists":102,"footer":171},"Produkt",{"dataNavLevelOne":97},"solutions",{"text":99,"config":100},"Alle Lösungen anzeigen",{"href":101,"dataGaName":97,"dataGaLocation":50},"/de-de/solutions/",[103,127,149],{"title":104,"description":105,"link":106,"items":111},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":107},{"icon":108,"href":109,"dataGaName":110,"dataGaLocation":50},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[112,115,118,123],{"text":26,"config":113},{"href":114,"dataGaLocation":50,"dataGaName":26},"/de-de/solutions/continuous-integration/",{"text":79,"config":116},{"href":84,"dataGaLocation":50,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":50,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatisierte Softwarebereitstellung",{"href":109,"dataGaLocation":50,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":50,"icon":134},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Application Security Testing",{"href":132,"dataGaName":139,"dataGaLocation":50},"Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":50,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":50},"/de-de/solutions/software-compliance/",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":50},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":50,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":50,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":50,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":50,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":50,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":50,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":50,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":282},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":50},"/de-de/resources/",[203,236,254],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":50},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":50},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":50,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":50},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":50},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":50},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":50},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":50},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":50},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":255,"items":256},"Vernetzen",[257,262,267,272,277],{"text":258,"config":259},"GitLab-Services",{"href":260,"dataGaName":261,"dataGaLocation":50},"/de-de/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":50},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":50},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Veranstaltungen",{"href":275,"dataGaName":276,"dataGaLocation":50},"/events/","events",{"text":278,"config":279},"Partner",{"href":280,"dataGaName":281,"dataGaLocation":50},"/de-de/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":287,"config":288},"the source promo card",{"src":289},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":291,"config":292},"Lies die News",{"href":293,"dataGaName":294,"dataGaLocation":50},"/de-de/the-source/","the source",{"text":296,"config":297,"lists":299},"Unternehmen",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"Über",{"href":305,"dataGaName":306,"dataGaLocation":50},"/de-de/company/","about",{"text":308,"config":309,"footerGa":312},"Karriere",{"href":310,"dataGaName":311,"dataGaLocation":50},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":50},{"text":316,"config":317},"Geschäftsführung",{"href":318,"dataGaName":319,"dataGaLocation":50},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":50},"/company/team/","team",{"text":326,"config":327},"Handbuch",{"href":328,"dataGaName":329,"dataGaLocation":50},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor Relations",{"href":333,"dataGaName":334,"dataGaLocation":50},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":50},"/de-de/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":50},"/de-de/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":50},"/company/contact/#contact-forms","newsletter",{"text":351,"config":352},"Presse",{"href":353,"dataGaName":354,"dataGaLocation":50},"/press/","press",{"text":356,"config":357,"lists":358},"Kontakt",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":57,"config":362},{"href":59,"dataGaName":363,"dataGaLocation":50},"talk to sales",{"text":365,"config":366},"Support-Portal",{"href":367,"dataGaName":368,"dataGaLocation":50},"https://support.gitlab.com","support portal",{"text":370,"config":371},"Kundenportal",{"href":372,"dataGaName":373,"dataGaLocation":50},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Schließen",{"text":377,"link":378},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":379,"config":380},"gitlab.com",{"href":64,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Vorschläge",[386,388,393,395,400,405],{"text":79,"config":387},{"href":84,"dataGaName":79,"dataGaLocation":382},{"text":389,"config":390},"Code Suggestions (KI)",{"href":391,"dataGaName":392,"dataGaLocation":382},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":26,"config":394},{"href":114,"dataGaName":26,"dataGaLocation":382},{"text":396,"config":397},"GitLab auf AWS",{"href":398,"dataGaName":399,"dataGaLocation":382},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":401,"config":402},"GitLab auf Google Cloud",{"href":403,"dataGaName":404,"dataGaLocation":382},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":406,"config":407},"Warum GitLab?",{"href":92,"dataGaName":408,"dataGaLocation":382},"Why GitLab?",{"freeTrial":410,"mobileIcon":415,"desktopIcon":420,"secondaryButton":423},{"text":411,"config":412},"Kostenlos testen",{"href":413,"dataGaName":55,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLab-Symbol",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":204,"config":424},{"href":425,"dataGaName":426,"dataGaLocation":414},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Erfahre mehr über GitLab Duo",{"href":84,"dataGaName":431,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":433},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":435},{"src":422,"dataGaName":419,"dataGaLocation":414},{"freeTrial":437,"mobileIcon":442,"desktopIcon":444},{"text":438,"config":439},"Zurück zur Preisübersicht",{"href":192,"dataGaName":440,"dataGaLocation":414,"icon":441},"back to pricing","GoBack",{"altText":416,"config":443},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":445},{"src":422,"dataGaName":419,"dataGaLocation":414},{"title":447,"button":448,"config":453},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":449,"config":450},"GitLab Transcend jetzt ansehen",{"href":451,"dataGaName":452,"dataGaLocation":50},"/de-de/events/transcend/virtual/","transcend event",{"layout":454,"icon":455,"disabled":32},"release","AiStar",{"data":457},{"text":458,"source":459,"edit":465,"contribute":470,"config":475,"items":480,"minimal":653},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":460,"config":461},"Quelltext der Seite anzeigen",{"href":462,"dataGaName":463,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":466,"config":467},"Diese Seite bearbeiten",{"href":468,"dataGaName":469,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":471,"config":472},"Beteilige dich",{"href":473,"dataGaName":474,"dataGaLocation":464},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":476,"facebook":477,"youtube":478,"linkedin":479},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[481,504,559,586,620],{"title":68,"links":482,"subMenu":487},[483],{"text":484,"config":485},"DevSecOps-Plattform",{"href":77,"dataGaName":486,"dataGaLocation":464},"devsecops platform",[488],{"title":190,"links":489},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":192,"dataGaName":493,"dataGaLocation":464},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":464},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":464},"/de-de/pricing/ultimate/","why ultimate",{"title":505,"links":506},"Lösungen",[507,512,515,517,522,527,531,534,537,542,544,546,549,554],{"text":508,"config":509},"Digitale Transformation",{"href":510,"dataGaName":511,"dataGaLocation":464},"/de-de/topics/digital-transformation/","digital transformation",{"text":513,"config":514},"Sicherheit und Compliance",{"href":132,"dataGaName":139,"dataGaLocation":464},{"text":124,"config":516},{"href":109,"dataGaName":110,"dataGaLocation":464},{"text":518,"config":519},"Agile Entwicklung",{"href":520,"dataGaName":521,"dataGaLocation":464},"/de-de/solutions/agile-delivery/","agile delivery",{"text":523,"config":524},"Cloud-Transformation",{"href":525,"dataGaName":526,"dataGaLocation":464},"/de-de/topics/cloud-native/","cloud transformation",{"text":528,"config":529},"SCM",{"href":121,"dataGaName":530,"dataGaLocation":464},"source code management",{"text":26,"config":532},{"href":114,"dataGaName":533,"dataGaLocation":464},"continuous integration & delivery",{"text":162,"config":535},{"href":164,"dataGaName":536,"dataGaLocation":464},"value stream management",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":464},"/de-de/solutions/gitops/","gitops",{"text":175,"config":543},{"href":177,"dataGaName":178,"dataGaLocation":464},{"text":180,"config":545},{"href":182,"dataGaName":183,"dataGaLocation":464},{"text":547,"config":548},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"dataGaLocation":464},{"text":550,"config":551},"Bildungswesen",{"href":552,"dataGaName":553,"dataGaLocation":464},"/de-de/solutions/education/","education",{"text":555,"config":556},"Finanzdienstleistungen",{"href":557,"dataGaName":558,"dataGaLocation":464},"/de-de/solutions/finance/","financial services",{"title":195,"links":560},[561,563,565,567,570,572,574,576,578,580,582,584],{"text":207,"config":562},{"href":209,"dataGaName":210,"dataGaLocation":464},{"text":212,"config":564},{"href":214,"dataGaName":215,"dataGaLocation":464},{"text":217,"config":566},{"href":219,"dataGaName":220,"dataGaLocation":464},{"text":222,"config":568},{"href":224,"dataGaName":569,"dataGaLocation":464},"docs",{"text":245,"config":571},{"href":247,"dataGaName":248,"dataGaLocation":464},{"text":240,"config":573},{"href":242,"dataGaName":243,"dataGaLocation":464},{"text":250,"config":575},{"href":252,"dataGaName":253,"dataGaLocation":464},{"text":258,"config":577},{"href":260,"dataGaName":261,"dataGaLocation":464},{"text":263,"config":579},{"href":265,"dataGaName":266,"dataGaLocation":464},{"text":268,"config":581},{"href":270,"dataGaName":271,"dataGaLocation":464},{"text":273,"config":583},{"href":275,"dataGaName":276,"dataGaLocation":464},{"text":278,"config":585},{"href":280,"dataGaName":281,"dataGaLocation":464},{"title":296,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":303,"config":589},{"href":305,"dataGaName":298,"dataGaLocation":464},{"text":308,"config":591},{"href":310,"dataGaName":311,"dataGaLocation":464},{"text":316,"config":593},{"href":318,"dataGaName":319,"dataGaLocation":464},{"text":321,"config":595},{"href":323,"dataGaName":324,"dataGaLocation":464},{"text":326,"config":597},{"href":328,"dataGaName":329,"dataGaLocation":464},{"text":331,"config":599},{"href":333,"dataGaName":334,"dataGaLocation":464},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":464},"/sustainability/",{"text":605,"config":606},"Vielfalt, Inklusion und Zugehörigkeit",{"href":607,"dataGaName":608,"dataGaLocation":464},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":610},{"href":338,"dataGaName":339,"dataGaLocation":464},{"text":346,"config":612},{"href":348,"dataGaName":349,"dataGaLocation":464},{"text":351,"config":614},{"href":353,"dataGaName":354,"dataGaLocation":464},{"text":616,"config":617},"Transparenzerklärung zu moderner Sklaverei",{"href":618,"dataGaName":619,"dataGaLocation":464},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":621,"links":622},"Nimm Kontakt auf",[623,626,631,633,638,643,648],{"text":624,"config":625},"Sprich mit einem Experten/einer Expertin",{"href":59,"dataGaName":60,"dataGaLocation":464},{"text":627,"config":628},"Support",{"href":629,"dataGaName":630,"dataGaLocation":464},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":370,"config":632},{"href":372,"dataGaName":373,"dataGaLocation":464},{"text":634,"config":635},"Status",{"href":636,"dataGaName":637,"dataGaLocation":464},"https://status.gitlab.com/","status",{"text":639,"config":640},"Nutzungsbedingungen",{"href":641,"dataGaName":642,"dataGaLocation":464},"/terms/","terms of use",{"text":644,"config":645},"Datenschutzerklärung",{"href":646,"dataGaName":647,"dataGaLocation":464},"/de-de/privacy/","privacy statement",{"text":649,"config":650},"Cookie-Einstellungen",{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":32},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,659],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":464},{"text":644,"config":658},{"href":646,"dataGaName":647,"dataGaLocation":464},{"text":649,"config":660},{"dataGaName":651,"dataGaLocation":464,"id":652,"isOneTrustButton":32},[662,675],{"id":663,"title":19,"body":9,"config":664,"content":666,"description":9,"extension":30,"meta":670,"navigation":32,"path":671,"seo":672,"stem":673,"__hash__":674},"blogAuthors/en-us/blog/authors/benjamin-skierlak.yml",{"template":665},"BlogAuthor",{"name":19,"config":667},{"headshot":668,"ctfId":669},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659471/Blog/Author%20Headshots/Benjamin_Skierlak_headshot.png","Kzp6pkUjPORYYMoeLFPRf",{},"/en-us/blog/authors/benjamin-skierlak",{},"en-us/blog/authors/benjamin-skierlak","RbLU9KGFtah9Juo58JyxfHHYNIU4fyzzOUb5p7-fubo",{"id":676,"title":20,"body":9,"config":677,"content":678,"description":9,"extension":30,"meta":682,"navigation":32,"path":683,"seo":684,"stem":685,"__hash__":686},"blogAuthors/en-us/blog/authors/james-wormwell.yml",{"template":665},{"name":20,"config":679},{"headshot":680,"ctfId":681},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659474/Blog/Author%20Headshots/james_wormwell_headshot.png","CPPijHb0Op5C5aVcvsOEf",{},"/en-us/blog/authors/james-wormwell",{},"en-us/blog/authors/james-wormwell","n6G4XENUWxgqOdCgfG0ECu0Uqj7qOS9zr3Rl8ouF49M",[688,701,715],{"content":689,"config":699},{"date":690,"body":691,"category":10,"tags":692,"authors":694,"title":696,"description":697,"heroImage":698},"2026-04-15","GitLab 17.0 enthielt 80 Breaking Changes – also inkompatible Änderungen, die beim Upgrade manuellen Anpassungsbedarf erzeugen. GitLab 18.0 hatte 27. Das bevorstehende Release GitLab 19.0 wird voraussichtlich 15 enthalten.\n\nWir wissen, dass die Verwaltung von Breaking Changes bei einem Major-Upgrade aufwändig ist: Es erfordert Analyse und Koordination im gesamten Unternehmen. Als Reaktion darauf haben wir eine [Genehmigungspflicht für Breaking Changes](https://docs.gitlab.com/development/deprecation_guidelines/#how-do-i-get-approval-to-move-forward-with-a-breaking-change) eingeführt, die eine Folgenabschätzung und die Freigabe durch die Führungsebene vorschreibt, bevor ein Breaking Change umgesetzt werden kann. Dieser Prozess zeigt Wirkung, und wir sind entschlossen, die Zahl weiter zu senken.\n\nIm Folgenden sind alle Breaking Changes in GitLab 19.0 aufgeführt, geordnet nach Deployment-Typ und Auswirkung, zusammen mit den Migrationsschritten für ein reibungsloses Upgrade.\n\n\n## Deployment-Fenster\n\n\nFolgende Deployment-Fenster sind relevant.\n\n### GitLab.com\n\nInkompatible Änderungen für GitLab.com sind auf diese zwei Fenster begrenzt:\n\n- **4.–6. Mai 2026** (09:00–22:00 UTC) — primäres Fenster\n- **11.–13. Mai 2026** (09:00–22:00 UTC) — Ausweichfenster\n\nViele weitere Änderungen werden im Laufe des Monats ausgerollt. Mehr zu den Breaking Changes innerhalb dieser Fenster in der [Dokumentation zu Breaking-Change-Fenstern](https://docs.gitlab.com/update/breaking_windows/).\n\n**Hinweis:** In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Fenster fallen.\n\n### GitLab Self-Managed\n\nGitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.\n\n> Mehr zum [Release-Zeitplan](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nDas Upgrade auf GitLab 19.0 findet im zugewiesenen Wartungsfenster statt. Das Wartungsfenster ist im Switchboard-Portal einsehbar. GitLab Dedicated-Instanzen werden auf Release N-1 gehalten, das Upgrade auf GitLab 19.0 erfolgt daher im Wartungsfenster in der Woche ab dem 22. Juni 2026.\n\nAuf der [Deprecations-Seite](https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0&breaking_only=true) ist die vollständige Liste der für GitLab 19.0 geplanten Entfernungen zu finden. Im Folgenden wird erläutert, was kommt und wie man sich je nach Deployment darauf vorbereitet.\n\n\n## Breaking Changes\n\n\nFolgende Breaking Changes haben hohe Auswirkungen.\n\n### Hohe Auswirkung\n\n**1. NGINX Ingress-Unterstützung durch Gateway API mit Envoy Gateway ersetzt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat NGINX Ingress als Standard-Netzwerkkomponente gebündelt. NGINX Ingress hat im März 2026 das End-of-Life erreicht. GitLab wechselt nun zu Gateway API mit Envoy Gateway als neuem Standard.\n\nAb GitLab 19.0 werden Gateway API und das gebündelte Envoy Gateway zur Standard-Netzwerkkonfiguration. Falls eine Migration zu Envoy Gateway für das eigene Deployment nicht sofort möglich ist, kann das gebündelte NGINX Ingress explizit wieder aktiviert werden — es bleibt bis zur geplanten Entfernung in GitLab 20.0 verfügbar.\n\nDiese Änderung betrifft nicht:\n\n- Das im Linux-Paket enthaltene NGINX\n- GitLab Helm chart- und GitLab Operator-Instanzen, die einen extern verwalteten Ingress- oder Gateway-API-Controller verwenden\n\nGitLab stellt bis zur vollständigen Entfernung Best-Effort-Sicherheitswartung für den geforkten NGINX Ingress chart und die zugehörigen Builds bereit. Für einen reibungslosen Übergang empfiehlt sich eine frühzeitige Migration zur bereitgestellten Gateway-API-Lösung oder zu einem extern verwalteten Ingress-Controller.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590800)\n\n\n**2. Gebündelte PostgreSQL-, Redis- und MinIO-Komponenten aus dem GitLab Helm chart entfernt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat Bitnami PostgreSQL, Bitnami Redis und einen Fork des offiziellen MinIO-Charts gebündelt, um die Einrichtung von GitLab in Proof-of-Concept- und Testumgebungen zu erleichtern. Aufgrund von Änderungen bei Lizenzierung, Projektpflege und Verfügbarkeit öffentlicher Images werden diese Komponenten ohne Ersatz aus dem GitLab Helm chart und dem GitLab Operator entfernt.\n\nDiese Charts sind ausdrücklich als nicht für den Produktionseinsatz geeignet dokumentiert. Ihr einziger Zweck war die Bereitstellung schneller Testumgebungen.\n\nWer eine Instanz mit gebündeltem PostgreSQL, Redis oder MinIO betreibt, muss vor dem Upgrade auf GitLab 19.0 der [Migrationsanleitung](https://docs.gitlab.com/charts/installation/migration/bundled_chart_migration/) folgen, um externe Dienste zu konfigurieren. Redis und PostgreSQL aus dem Linux-Paket sind von dieser Änderung nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590797)\n\n\n**3. Resource Owner Password Credentials (ROPC) OAuth Grant entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie Unterstützung für den Resource Owner Password Credentials (ROPC) Grant als OAuth-Flow wird in GitLab 19.0 vollständig entfernt. Dies entspricht dem OAuth RFC Version 2.1-Standard, der ROPC aufgrund seiner inhärenten Sicherheitsschwächen entfernt.\n\nGitLab hat seit dem 8. April 2025 bereits eine Client-Authentifizierung für ROPC auf GitLab.com vorgeschrieben. In Version 18.0 wurde eine Administrator-Einstellung hinzugefügt, die einen kontrollierten Opt-out vor der Entfernung ermöglicht.\n\nNach dem Upgrade auf 19.0 kann ROPC unter keinen Umständen mehr verwendet werden, auch nicht mit Client-Credentials. Alle Anwendungen oder Integrationen, die diesen Grant-Typ verwenden, müssen vor dem Upgrade auf einen unterstützten OAuth-Flow migrieren — beispielsweise den Authorization Code Flow.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/457353)\n\n\n**4. PostgreSQL 16 nicht mehr unterstützt — PostgreSQL 17 ist das neue Minimum**\n\n_GitLab Self-Managed_\n\nGitLab folgt einem [jährlichen Upgrade-Rhythmus für PostgreSQL](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/). In GitLab 19.0 wird PostgreSQL 17 zur Mindestanforderung, die Unterstützung für PostgreSQL 16 wird eingestellt.\n\nPostgreSQL 17 ist ab GitLab 18.9 verfügbar und kann jederzeit vor dem 19.0-Release upgradet werden.\n\nBei Instanzen mit einer einzelnen, über das Linux-Paket installierten PostgreSQL-Instanz wird beim Upgrade auf 18.11 möglicherweise ein automatisches Upgrade auf PostgreSQL 17 durchgeführt. Für das Upgrade ist ausreichend freier Speicherplatz einzuplanen.\n\nBei Instanzen mit PostgreSQL Cluster oder solchen, die das automatische Upgrade deaktivieren, ist vor dem Upgrade auf GitLab 19.0 ein manuelles Upgrade auf PostgreSQL 17 erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/589774) | [Upgrade-Anleitung](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n\n\n### Mittlere Auswirkung\n\nFolgende Breaking Changes haben mittlere Auswirkungen.\n\n**1. Linux-Paket-Unterstützung für Ubuntu 20.04 eingestellt**\n\n_GitLab Self-Managed_\n\nDer Standard-Support für Ubuntu 20.04 endete im Mai 2025. Gemäß der [Richtlinie für unterstützte Plattformen im Linux-Paket](https://docs.gitlab.com/install/package/#supported-platforms) werden Pakete eingestellt, sobald ein Anbieter den Support für das Betriebssystem beendet.\n\nAb GitLab 19.0 werden keine Pakete mehr für Ubuntu 20.04 bereitgestellt. GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distribution.\n\nWer GitLab derzeit auf Ubuntu 20.04 betreibt, muss vor dem Upgrade auf GitLab 19.0 auf Ubuntu 22.04 oder ein anderes [unterstütztes Betriebssystem](https://docs.gitlab.com/install/package/#supported-platforms) wechseln. Canonical stellt eine [Upgrade-Anleitung](https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/) für die Migration bereit.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915)\n\n\n**2. Unterstützung für Redis 6 entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Unterstützung für Redis 6 entfernt. Instanzen mit einem externen Redis-6-Deployment müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migrieren; Valkey 7.2 ist ab GitLab 18.9 in der Beta verfügbar, die allgemeine Verfügbarkeit ist für GitLab 19.0 geplant.\n\nDas im Linux-Paket enthaltene Redis verwendet seit GitLab 16.2 Redis 7 und ist nicht betroffen. Handlungsbedarf besteht nur bei Instanzen mit einem externen Redis-6-Deployment.\n\nMigrationsressourcen für gängige Plattformen:\n\n- **AWS ElastiCache:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/supported-engine-versions.html)\n- **GCP Memorystore:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://cloud.google.com/memorystore/docs/redis/supported-versions)\n- **Azure Cache for Redis:** Managed Redis 7.2 oder Valkey 7.2 ist auf Azure noch nicht verfügbar. Als Alternative kann ein selbstgehostetes Deployment auf Azure VMs oder AKS genutzt werden, oder die Linux-Paket-Installation, die Valkey 7.2 mit GitLab 19.0 GA unterstützen wird.\n- **Self-hosted:** Upgrade der Redis-6-Instanz auf Redis 7.2 oder Valkey 7.2.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585839) | [Anforderungsdokumentation](https://docs.gitlab.com/install/requirements/)\n\n\n**3. `heroku/builder:22`-Image durch `heroku/builder:24` ersetzt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Cloud-Native-Buildpack (CNB) Builder-Image in Auto DevOps wurde auf `heroku/builder:24` aktualisiert. Betroffen sind Pipelines, die das [`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image) der [Auto Build-Stage von Auto DevOps](https://docs.gitlab.com/topics/autodevops/stages/#auto-build) verwenden.\n\nDie meisten Workloads sind nicht betroffen. Für einige Nutzende kann dies jedoch ein Breaking Change sein. Vor dem Upgrade sollten die [Heroku-24-Stack-Release-Notes](https://devcenter.heroku.com/articles/heroku-24-stack#what-s-new) und [Upgrade-Hinweise](https://devcenter.heroku.com/articles/heroku-24-stack#upgrade-notes) geprüft werden.\n\nWer nach GitLab 19.0 weiterhin `heroku/builder:22` verwenden möchte, setzt die CI/CD-Variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` auf `heroku/builder:22`.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79)\n\n\n**4. Mattermost aus dem Linux-Paket entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird das gebündelte Mattermost aus dem Linux-Paket entfernt. Mattermost wurde seit 2015 mit GitLab gebündelt, verfügt inzwischen aber über ausgereifte eigenständige Deployment-Optionen. Mit Mattermost v11 wurde zudem [GitLab SSO aus dem kostenlosen Angebot entfernt](https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126), was den Mehrwert der gebündelten Integration verringert.\n\nWer das gebündelte Mattermost nicht verwendet, ist nicht betroffen. Bei Bedarf steht in der Mattermost-Dokumentation eine Anleitung zur [Migration von GitLab Omnibus zu Mattermost Standalone](https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html) zur Verfügung.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590798)\n\n\n**5. Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt. Betroffen sind:\n\n- openSUSE Leap 15.6\n- SUSE Linux Enterprise Server 12.5\n- SUSE Linux Enterprise Server 15.6\n\nGitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distributionen. Der empfohlene Weg ist eine Migration zu einem [Docker-Deployment von GitLab](https://docs.gitlab.com/install/docker/installation/) auf der bestehenden Distribution — so ist kein Wechsel des Betriebssystems nötig, um weiterhin Upgrades zu erhalten.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590801)\n\n\n### Geringe Auswirkung\n\nFolgende Breaking Changes haben geringe Auswirkungen.\n\n**1. Spamcheck aus Linux-Paket und GitLab Helm chart entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird [Spamcheck](https://docs.gitlab.com/administration/reporting/spamcheck/) aus dem Linux-Paket und dem GitLab Helm chart entfernt. Es ist in erster Linie für große öffentliche Instanzen relevant — ein Sonderfall in der GitLab-Kundenbasis. Die Entfernung reduziert die Paketgröße und den Abhängigkeits-Footprint für die Mehrheit der Nutzenden.\n\nWer Spamcheck nicht verwendet, ist nicht betroffen. Wer das gebündelte Spamcheck nutzt, kann es separat über [Docker](https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck) bereitstellen. Eine Datenmigration ist nicht erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590796)\n\n\n**2. Slack-Slash-Commands-Integration entfernt**\n\n_GitLab Self-Managed | Dedicated_\n\nDie [Slack-Slash-Commands-Integration](https://docs.gitlab.com/user/project/integrations/slack_slash_commands/) wird zugunsten der [GitLab for Slack-App](https://docs.gitlab.com/user/project/integrations/gitlab_slack_application/) eingestellt, die eine sicherere Integration mit denselben Funktionen bietet.\n\nAb GitLab 19.0 können Slack Slash Commands nicht mehr konfiguriert oder verwendet werden. Diese Integration existiert nur in GitLab Self-Managed und GitLab Dedicated — GitLab.com-Nutzende sind nicht betroffen.\n\nOb die eigene Instanz betroffen ist, lässt sich mit der [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345#am-i-impacted) feststellen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345)\n\n\n**3. Bitbucket-Cloud-Import über API unterstützt keine App-Passwörter mehr**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nAtlassian hat App-Passwörter (Benutzername-Passwort-Authentifizierung) für Bitbucket Cloud eingestellt und angekündigt, dass diese Authentifizierungsmethode ab dem 9. Juni 2026 nicht mehr funktioniert.\n\nAb GitLab 19.0 erfordert der Import von Repositories aus Bitbucket Cloud über die GitLab API [User-API-Tokens](https://support.atlassian.com/organization-administration/docs/understand-user-api-tokens/) anstelle von App-Passwörtern. Nutzende, die aus Bitbucket Server oder über die GitLab-Benutzeroberfläche aus Bitbucket Cloud importieren, sind nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961) | [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961#am-i-impacted)\n\n\n**4. Trending-Tab auf der Seite „Projekte erkunden\" entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDer Tab **Trending** unter **Erkunden > Projekte** und die zugehörigen GraphQL-Argumente werden in GitLab 19.0 entfernt. Der Trending-Algorithmus berücksichtigt nur öffentliche Projekte und ist daher für Self-Managed-Instanzen, die hauptsächlich interne oder private Projektsichtbarkeit verwenden, nicht zielführend.\n\nIm Monat vor dem GitLab-19.0-Release wird der Tab **Trending** auf GitLab.com auf den Tab **Aktiv**, sortiert nach Sternen in absteigender Reihenfolge, weitergeleitet.\n\nEbenfalls entfernt: das `trending`-Argument in den GraphQL-Typen `Query.adminProjects`, `Query.projects` und `Organization.projects`.\n\n[Deprecation notice](https://gitlab.com/groups/gitlab-org/-/work_items/18493)\n\n\n**5. Container-Registry-Speichertreiber-Updates**\n\n_GitLab Self-Managed_\n\nZwei ältere Container-Registry-Speichertreiber werden in GitLab 19.0 ersetzt:\n\n- **Azure-Speichertreiber:** Der ältere `azure`-Treiber wird zu einem Alias für den neuen `azure_v2`-Treiber. Es ist keine manuelle Aktion erforderlich, eine proaktive Migration wird jedoch für verbesserte Zuverlässigkeit und Leistung empfohlen. Migrationsschritte sind in der [Object-Storage-Dokumentation](https://docs.gitlab.com/administration/packages/container_registry/#use-object-storage) beschrieben. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523096)\n\n- **S3-Speichertreiber (AWS SDK v1):** Der ältere `s3`-Treiber wird zu einem Alias für den neuen `s3_v2`-Treiber. Der `s3_v2`-Treiber unterstützt Signature Version 2 nicht — eine vorhandene `v4auth: false`-Konfiguration wird transparent ignoriert. Vor dem Upgrade ist eine Migration auf Signature Version 4 erforderlich. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523095)\n\n\n**6. `ciJobTokenScopeAddProject`-GraphQL-Mutation entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie `ciJobTokenScopeAddProject`-GraphQL-Mutation wird zugunsten von `ciJobTokenScopeAddGroupOrProject` eingestellt, das zusammen mit den CI/CD-Job-Token-Scope-Änderungen in GitLab 18.0 eingeführt wurde. Automatisierungen oder Tools, die die veraltete Mutation verwenden, müssen vor dem Upgrade aktualisiert werden.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/474175)\n\n\n**7. `ci_job_token_scope_enabled`-Attribut der Projects API entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Attribut `ci_job_token_scope_enabled` in der [Projects REST API](https://docs.gitlab.com/api/projects/) wird in GitLab 19.0 entfernt. Das Attribut wurde in GitLab 18.0 eingestellt, als die zugrundeliegende Einstellung entfernt wurde, und hat seitdem stets `false` zurückgegeben.\n\nZur Steuerung des CI/CD-Job-Token-Zugriffs werden die [CI/CD-Job-Token-Projekteinstellungen](https://docs.gitlab.com/ci/jobs/ci_job_token/#control-job-token-access-to-your-project) verwendet.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/423091)\n\n\n**8. Paginierungslimit für nicht authentifizierte Projects-API auf GitLab.com eingeführt**\n\n_GitLab.com_\n\nZur Sicherstellung der Plattformstabilität und konsistenten Leistung wird für alle nicht authentifizierten Anfragen an die Projects-List-REST-API auf GitLab.com ein maximales Offset-Limit von 50.000 eingeführt. Beispielsweise ist der `page`-Parameter bei 20 Ergebnissen pro Seite auf 2.500 Seiten begrenzt.\n\nWorkflows, die Zugriff auf mehr Daten benötigen, müssen keyset-basierte Paginierungsparameter verwenden. Dieses Limit gilt nur für GitLab.com. In GitLab Self-Managed und GitLab Dedicated ist das Offset-Limit standardmäßig deaktiviert und hinter einem Feature-Flag verfügbar.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585176)\n\n\n## Ressourcen zur Folgenabschätzung\n\nGitLab stellt spezifische Tools bereit, mit denen sich die Auswirkungen der geplanten Änderungen auf die eigene GitLab-Instanz analysieren lassen. Nach der Folgenabschätzung empfiehlt sich die Prüfung der Migrationsschritte in der jeweiligen Dokumentation für einen reibungslosen Übergang zu GitLab 19.0.\n\n**[GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective) (nur Self-Managed):** Dieses experimentelle Tool prüft eine GitLab-Installation automatisch auf bekannte Probleme, indem es Konfigurationsdateien und Datenbankwerte analysiert. Hinweis: Es muss direkt auf den GitLab-Nodes ausgeführt werden.\n\nNutzende mit einem kostenpflichtigen Plan, die Fragen haben oder Unterstützung bei diesen Änderungen benötigen, können ein Support-Ticket im [GitLab Support-Portal](https://support.gitlab.com/) eröffnen.\n\nKostenlose GitLab.com-Nutzende können zusätzlichen Support über Community-Ressourcen wie die [GitLab-Dokumentation](https://docs.gitlab.com/), das [GitLab Community Forum](https://forum.gitlab.com/) und [Stack Overflow](https://stackoverflow.com/questions/tagged/gitlab) erhalten.\n",[10,693],"news",[695],"Martin Brümmer","Ein Leitfaden zu den Breaking Changes in GitLab 19.0","GitLab 19.0 steht vor der Tür: Was sich ändert, welche Anpassungen das eigene Deployment erfordert und wie man sich auf das Upgrade vorbereitet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png",{"featured":13,"template":14,"slug":700},"a-guide-to-the-breaking-changes-in-gitlab-19-0",{"content":702,"config":713},{"title":703,"description":704,"heroImage":705,"category":10,"tags":706,"authors":708,"date":711,"body":712},"Testergebnisse aus GitLab-Pipelines automatisch in QMetry übertragen","Der QMetry GitLab Component überträgt Testergebnisse automatisch aus CI/CD-Pipelines in QMetry – ohne manuelle Schritte, mit vollständigem Audit-Trail.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775486753/cswmwtygkgkbdsibo09v.png",[28,10,707],"devops",[709,710],"Matt Genelin","Matt Bonner","2026-04-07","In modernen Entwicklungsumgebungen müssen DevSecOps-Teams Testergebnisse aus CI/CD-Pipelines konsistent in Testmanagement-Plattformen übertragen, um Transparenz, Nachvollziehbarkeit und Compliance über den gesamten Entwicklungszyklus zu gewährleisten.\nTeams, die GitLab für CI/CD und SmartBear QMetry für das Testmanagement einsetzen, verbringen Zeit mit manuellem Export und Import von Testergebnissen – das verzögert Feedback und erschwert eine zuverlässige, zentrale Testsicht.\nDer **QMetry GitLab Component** automatisiert diesen Prozess. Die wiederverwendbare CI/CD-Komponente, verfügbar im [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog), überträgt Testausführungsdaten nach jeder Pipeline-Ausführung automatisch nach QMetry – einer KI-gestützten, unternehmenstauglichen Testmanagement-Plattform, die Testplanung, -ausführung, -nachverfolgung und -reporting in einer Lösung vereint.\nAls zentrales System der Aufzeichnung für Tests hilft QMetry Teams dabei, Abdeckung und Ausführung nachzuverfolgen und fundiertere Release-Entscheidungen zu treffen.\n![SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ojt707rzxnm2yr3vqxdh.png)\n\n## Vorteile der Integration\n\n### Manuelle Uploads entfallen, Nachvollziehbarkeit steigt\nDevSecOps-Engineers und QA-Teams müssen Testergebnisse nicht mehr manuell exportieren und importieren – die Komponente übernimmt das automatisch nach jeder Pipeline-Ausführung. Zugleich erhalten Teams vollständige Nachvollziehbarkeit von Anforderungen über Testfälle bis hin zu tatsächlichen Ausführungsergebnissen.\n\n![Test results with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ajx64sihup2nursdpnxz.png)\n\n### Compliance- und Audit-Anforderungen erfüllen\nFür Organisationen in regulierten Branchen ist lückenlose Testdokumentation nicht verhandelbar. Die Integration stellt sicher, dass jede Testausführung in QMetry mit Verknüpfungen zur jeweiligen GitLab-Pipeline, zum Commit und zum Build dokumentiert wird – ohne zusätzlichen manuellen Aufwand.\n![Audit-ready record of testing with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/q2tbaw5otgdywjkcquqx.png)\n\n### KI-gestützte Test-Insights nutzen\nQMetry analysiert mithilfe von KI Testausführungsmuster, identifiziert instabile Tests, prognostiziert Testfehler und empfiehlt Optimierungsmöglichkeiten. Echtzeit-Daten aus GitLab-Pipelines maximieren den Wert dieser Funktionen.\n![Genaue Insights mit SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/pl7ru4wx8ixnheedfyrs.png)\n\n## Über die GitLab-SmartBear-Partnerschaft\nDiese Komponente steht für die wachsende Partnerschaft zwischen GitLab und SmartBear, CI/CD-Ausführung und Testmanagement in einem Workflow zu verbinden. Gemeinsam helfen sie Teams, Testing in den Entwicklungszyklus zu integrieren und dabei die Qualitäts-, Sicherheits- und Compliance-Standards ihrer Branchen einzuhalten.\n\n## Praxisbeispiele\n\n### Finanzdienstleistungen: Enterprise-Banking-Plattformen\nFührende Finanzinstitute stehen vor besonderen Herausforderungen beim Skalieren von Testautomatisierung:\n* **Regulatorische Compliance**: Detaillierte Audit-Trails für alle Testaktivitäten erforderlich\n* **Mehrere Compliance-Frameworks**: BaFin BAIT, PSD2, DSGVO und interne Risikomanagement-Richtlinien\n* **Hochfrequente Deployments**: Mehrere Produktions-Deployments täglich über Microservices\n* **Verteilte Teams**: Echtzeit-Transparenz über globale Engineering-Teams hinweg erforderlich\nFinanzdienstleister, die den QMetry GitLab Component einsetzen, automatisieren Testergebnis-Uploads für Unit-Tests, API-Contract-Tests, End-to-End-Tests für Transaktionsabläufe sowie Security- und Performance-Testergebnisse.\n\n**Mögliche Ergebnisse**:\n* **Deutliche Reduzierung** des manuellen Test-Reporting-Aufwands\n* **Vollständige Audit-Trail-Abdeckung** für Regulierungsprüfungen\n* **Echtzeit-Transparenz** für verteilte QA-Teams\n* **Verbesserte Compliance-Position** durch vollständige Nachvollziehbarkeit von Anforderungen bis zur Testausführung\n\n### Flugregelungssoftware in der Luft- und Raumfahrt\nDie Softwareentwicklung in der Luft- und Raumfahrt unterliegt besonderen Anforderungen:\n* **DO-178C-Compliance**: Avioniksoftware muss strikte Zertifizierungsstandards erfüllen\n* **Vollständige Nachvollziehbarkeit**: Jede Anforderung verknüpft mit Testfällen und Ausführungsergebnissen\n* **Audit-Trails**: Zertifizierungsbehörden verlangen detaillierte Aufzeichnungen aller Testaktivitäten\n* **Mehrere Teststufen**: Unit-, Integrations-, System- und Zertifizierungstests\nDurch die Integration von GitLab CI/CD mit QMetry automatisiert das Aerospace-Engineering-Team Testausführung und Reporting über alle Teststufen hinweg.\n\n**Vor der Integration**:\n* Manueller Export aus GitLab, Import in QMetry über UI-Uploads\n* Prozess dauerte 2–3 Stunden pro Testzyklus\n* Fehlerrisiko bei der Dateneingabe, verzögerte Rückmeldung an Stakeholder\n\n**Nach der Integration**:\n* Testergebnisse fließen automatisch von GitLab nach QMetry\n* Vollständiger Audit-Trail vom Commit über den Test bis zum Ergebnis\n* Kein manueller Eingriff, Echtzeit-Transparenz für Zertifizierungsprüfer\n* Compliance-Reports werden automatisch erstellt\n\n**Beispiel-Dashboard in QMetry nach der Integration**:\n```none\n    ╔════════════════════════════════════════════════════════════╗\n    ║  Flight Control System v2.4 - Test Execution Dashboard     ║\n    ╠════════════════════════════════════════════════════════════╣\n    ║                                                            ║\n    ║  📊 Test Execution Summary (Last 7 Days)                   ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  ✓ Total Tests Executed: 1,247                             ║\n    ║  ✓ Passed: 1,241 (99.5%)                                   ║\n    ║  ✗ Failed: 6 (0.5%)                                        ║\n    ║  ⏸ Skipped: 0                                              ║\n    ║                                                            ║\n    ║  📁 Test Suite Organization                                ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  └─ Certification/                                         ║\n    ║     └─ DO-178C/                                            ║\n    ║        ├─ Unit/ (487 tests, 100% pass)                     ║\n    ║        ├─ Integration/ (623 tests, 99.2% pass)             ║\n    ║        └─ System/ (137 tests, 100% pass)                   ║\n    ║                                                            ║\n    ║  🔗 Traceability                                           ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  Requirements Covered: 342/342 (100%)                      ║\n    ║  Test Cases Linked: 1,247/1,247 (100%)                     ║\n    ║  GitLab Pipeline Executions: 47 (automated)                ║\n    ║                                                            ║\n    ║  ⚠️  Action Items                                          ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  • 6 failed tests require investigation                    ║\n    ║  • Last execution: 2 minutes ago (Pipeline #1543)          ║\n    ║  • GitLab Commit: a7f8c23 \"Fix altitude hold logic\"        ║\n    ║                                                            ║\n    ╚════════════════════════════════════════════════════════════╝\n    \n```\n### Compliance- und Audit-Vorteile\n\n**Für Finanzdienstleister (BaFin BAIT, PSD2, SOX)**:\n1. **Automatische Nachvollziehbarkeit**: Regulatorische Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits verknüpft\n2. **Auditfähige Dokumentation**: Vollständige Testausführungshistorie mit Zeitstempeln und Pipeline-Referenzen\n3. **Regulatorisches Reporting**: Compliance-Reports direkt aus QMetry-Testdaten generieren\n\n**Für die Luft- und Raumfahrt-Zertifizierung (DO-178C, DO-254)**:\n1. **Automatische Nachverfolgbarkeitsmatrix**: Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits\n2. **Unveränderlicher Audit-Trail**: Pipeline-ID, Commit-SHA und Ausführer für jede Testausführung gestempelt\n3. **Zertifizierungspaket-Generierung**: Konforme Dokumentation aus GitLab-Pipeline-Daten\n\n---\n\n## Technische Umsetzung\n*Dieser Abschnitt orientiert Teams, die die Integration einrichten möchten. Die vollständige Schritt-für-Schritt-Anleitung mit allen Konfigurationsdetails – API-Credentials, CI/CD-Variablen, Testformate, erweiterte Optionen und Fehlerbehebung – ist im [englischen Originalbeitrag](https://about.gitlab.com/blog/streamline-test-management-with-the-smartbear-qmetry-gitlab-component/) verfügbar.*\n\n## Voraussetzungen\n* **GitLab-Account** mit einem Projekt, das automatisierte Tests enthält und Testergebnisdateien erzeugt (JUnit XML, TestNG XML usw.)\n* **QMetry Test Management Enterprise**-Account mit aktiviertem API-Zugriff und generiertem API-Key\n* **QMetry-Projekt**, bereits angelegt, in das Testergebnisse hochgeladen werden sollen\n* **Kenntnisse in GitLab CI/CD**, einschließlich grundlegender `.gitlab-ci.yml`-Syntax\n### Ablauf der Testergebnis-Übertragung\n1. **Testausführung**: Die GitLab CI/CD-Pipeline führt automatisierte Tests aus.\n2. **Ergebnisgenerierung**: Tests erzeugen Ausgabedateien (JUnit XML, TestNG XML usw.).\n3. **Komponentenaufruf**: Die QMetry-Komponente wird als Job in der Pipeline ausgeführt.\n4. **Automatischer Upload**: Die Komponente liest die Testergebnisdateien und lädt sie via API nach QMetry hoch.\n5. **QMetry-Verarbeitung**: QMetry empfängt die Ergebnisse und stellt sie für Reporting und Analyse bereit.\n\n## Basisintegration\nDie Komponente in der `.gitlab-ci.yml`-Datei einbinden. Die Komponente sollte **nach** dem Abschluss der Tests ausgeführt werden:\n```yaml\n    include:\n      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n        inputs:\n          stage: test\n          project: \"Aerospace Flight Control System\"\n          file_name: \"results.xml\"\n          testing_type: \"JUNIT\"\n          instance_url: ${INSTANCE_URL}\n          api_key: ${QMETRY_API_KEY}\n  ```\n\n\n| Parameter | Beschreibung | Beispiel |\n| ----- | ----- | ----- |\n| `stage` | CI/CD-Stage für den Upload-Job | `test` |\n| `project` | QMetry-Projektname oder -Schlüssel | `\"Aerospace Flight Control System\"` |\n| `file_name` | Pfad zur Testergebnisdatei | `\"results.xml\"` |\n| `testing_type` | Format der Testergebnisse | `\"JUNIT\"` (auch: `TESTNG`, `NUNIT` usw.) |\n| `instance_url` | QMetry-Instanz-URL | `${INSTANCE_URL}` (aus CI/CD-Variablen) |\n| `api_key` | QMetry API-Key zur Authentifizierung | `${QMETRY_API_KEY}` (aus CI/CD-Variablen) |\n\n## Vollständiges Pipeline-Beispiel\n```yaml\n    stages:\n      - test\n      - report\n\n    variables:\n      NODE_VERSION: \"18\"\n\n    unit-tests:\n      stage: test\n      image: node:${NODE_VERSION}\n      script:\n        - npm ci\n        - npm run test:unit -- --reporter=junit --reporter-options=output=results.xml\n      artifacts:\n        reports:\n          junit: results.xml\n        paths:\n          - results.xml\n        when: always\n      tags:\n        - docker\n\n    include:\n      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n        inputs:\n          stage: test\n          project: \"Aerospace Flight Control System\"\n          file_name: \"results.xml\"\n          testing_type: \"JUNIT\"\n          instance_url: ${INSTANCE_URL}\n          api_key: ${QMETRY_API_KEY}\n```\n\n## Vollständige Konfigurationsreferenz\n| Eingabeparameter | Pflichtfeld | Standard | Beschreibung |\n| ----- | ----- | ----- | ----- |\n| `stage` | Nein | `test` | GitLab CI/CD-Stage für den Upload-Job |\n| `runner_tag` | Nein | `\"\"` | Spezifischer Runner-Tag (leer = beliebiger verfügbarer Runner) |\n| `project` | Ja | – | QMetry-Projektname oder -Schlüssel |\n| `file_name` | Ja | – | Pfad zur Testergebnisdatei (relativ zum Projektstamm) |\n| `testing_type` | Ja | – | Testergebnisformat: `JUNIT`, `TESTNG`, `NUNIT` usw. |\n| `skip_warning` | Nein | `\"1\"` | Warnungen beim Import überspringen (`\"1\"` = überspringen, `\"0\"` = anzeigen) |\n| `is_matching_required` | Nein | `\"false\"` | Bestehende Testfälle nach Name abgleichen (`\"true\"` oder `\"false\"`) |\n| `testsuite_name` | Nein | `\"\"` | Name für die Test-Suite in QMetry |\n| `testsuite_id` | Nein | `\"\"` | Bestehende Test-Suite-ID, an die Ergebnisse angehängt werden |\n| `testsuite_folder_path` | Nein | `\"\"` | Ordnerpfad für die Test-Suite-Organisation (z. B. `/Regression/Sprint-23`) |\n| `automation_hierarchy` | Nein | `\"\"` | Hierarchieebene für die Testorganisation (`\"1\"`, `\"2\"`, `\"3\"` usw.) |\n| `testcase_fields` | Nein | `\"\"` | Benutzerdefinierte Felder für Testfälle (kommagetrennt: `field1=value1,field2=value2`) |\n| `testsuite_fields` | Nein | `\"\"` | Benutzerdefinierte Felder für Test-Suites (kommagetrennt: `field1=value1,field2=value2`) |\n| `instance_url` | Ja | – | QMetry-Instanz-URL (in CI/CD-Variablen speichern) |\n| `api_key` | Ja | – | QMetry API-Key (in CI/CD-Variablen speichern, maskiert) |\n\n## Dokumentation und Support\n* **Komponentendokumentation**: [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog)\n* **Komponenten-Repository**: [gitlab.com/sb9945614/qtm-gitlab-component](https://gitlab.com/sb9945614/qtm-gitlab-component)\n* **QMetry-Dokumentation**: [QMetry Support Portal](https://qmetrysupport.atlassian.net/wiki/spaces/QPro/overview)\n* **SmartBear-Ressourcen**: [SmartBear Academy](https://smartbear.com/resources/)\n* **GitLab CI/CD-Dokumentation**: [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)\n* **QMetry-Support**: support@smartbear.com – [QMetry Community Forum](https://community.smartbear.com/)",{"featured":32,"template":14,"slug":714},"streamline-test-management-with-the-smartbear-qmetry-gitlab-component",{"content":716,"config":724},{"title":717,"description":718,"authors":719,"heroImage":698,"date":711,"body":721,"category":10,"tags":722},"GitLab Duo CLI: Agentenbasierte KI jetzt auch im Terminal","GitLab Duo CLI bringt agentenbasierte KI der Duo Agent Platform ins Terminal – mit interaktivem Chat-Modus und Headless-Modus für CI/CD-Automatisierung.",[720],"John Coghlan","Wer Pipelines debuggt oder KI in automatisierte CI/CD-Workflows integriert, ohne dass jemand dabei zusieht, kommt mit bisherigen KI-Assistenten schnell an Grenzen: Diese konzentrieren sich auf Code-Erstellung und decken damit nur einen Teil des Software-Lebenszyklus ab. GitLab Duo CLI, jetzt in der öffentlichen Beta, schließt diese Lücke.\n\nGitLab Duo CLI bringt die agentenbasierte KI der [Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/) ins Terminal – mit vollständiger Unterstützung für automatisierte Workflows und einem interaktiven Chat-Modus, wenn ein Mensch im Loop bleiben soll. Dieser Artikel beschreibt, was Duo CLI leistet, wie die beiden Betriebsmodi funktionieren und welches Sicherheitsmodell dahintersteht.\n\n## GitLab Duo CLI installieren\n\nWer GLab (die GitLab CLI) bereits installiert hat, führt folgenden Befehl aus:\n\n```\nglab duo cli\n```\n\nAnschließend einfach den Anweisungen folgen.\n\nOhne GLab: [Hier installieren](https://gitlab.com/gitlab-org/cli/#installation) oder [Duo CLI als eigenständiges Tool verwenden](https://docs.gitlab.com/user/gitlab_duo_cli/#without-the-gitlab-cli).\n\n## Warum das Terminal – und warum jetzt\n\nDie erste Generation von KI-Assistenten für die Softwareentwicklung war auf die IDE ausgerichtet und konzentrierte sich ausschließlich auf Code-Erstellung. Das war sinnvoll, solange Autovervollständigung im Vordergrund stand. Sobald KI-Agenten jedoch eigenständig handeln – Tests ausführen, Pipelines auslösen, Vulnerability-Scans überwachen und mehr – reicht die IDE als einzige Abstraktionsebene nicht mehr aus.\n\nDie besten Entwickler-Tools funktionieren sowohl für Menschen als auch für Maschinen. CLIs haben sich über Jahrzehnte in genau diese Richtung entwickelt. Sie sind komponierbar: Output lässt sich weiterleiten, Befehle verketten, Skripte einbetten. Sie sind nachvollziehbar: Wenn etwas schiefläuft, führt man denselben Befehl aus und sieht genau, was der Agent gesehen hat. Und sie sind transparent: keine Hintergrundprozesse, kein Initialisierungsaufwand, kein Protokoll, das beim Fehlerfall erst entschlüsselt werden muss.\n\nTerminal-Interfaces eignen sich besser für Automatisierung, Scripting und portable Umgebungen. IDE-Interfaces bieten sich für interaktive, kontextreiche Entwicklung an. GitLab Duo CLI ist für ersteres ausgelegt – Duo Agentic Chat in IDE und UI deckt letzteres ab.\n\n## Was GitLab Duo CLI kann\n\nMit GitLab Duo CLI lässt sich Code erstellen, anpassen, refaktorieren und modernisieren – vergleichbar mit anderen KI-gestützten Coding-Assistenten für das Terminal. Darüber hinaus sind alle Agenten und Flows der GitLab Duo Agent Platform über Duo CLI zugänglich: von der Automatisierung von CI/CD-Konfigurationen und Pipeline-Optimierungen bis hin zur autonomen Ausführung mehrstufiger Entwicklungsaufgaben über den gesamten Software-Lebenszyklus.\n\nGitLab Duo CLI läuft in zwei Modi:\n\n* **Interaktiver Modus** – eine editor-unabhängige Terminal-Chat-Umgebung mit menschlicher Freigabe vor jeder Aktion. Geeignet für das Verstehen von Codebase-Strukturen, das Erstellen von Code, die Fehlersuche oder das Troubleshooting von Pipelines.\n* **Headless-Modus** – nicht-interaktiv, ausgelegt für Runner, Skripte und automatisierte Workflows. Direkt in CI/CD einbinden, ohne manuelle Eingriffe.\n\n## KI mit Leitplanken\n\nAgentenbasierte KI, die eigenständig Aktionen ausführen kann, birgt reale Sicherheitsrisiken. GitLab Duo CLI adressiert diese auf Plattformebene – nicht nachträglich:\n\n* **Human-in-the-Loop standardmäßig** im interaktiven Modus: Keine Aktion wird ohne Freigabe ausgeführt.\n* **Prompt-Injection-Erkennung** ist in der GitLab Duo Agent Platform integriert, nicht nachgerüstet.\n* **Composite Identity** – eine kombinierte Identität, die sowohl den Nutzenden als auch den Agenten repräsentiert – begrenzt die Zugriffsrechte des Agenten und macht jede KI-gesteuerte Aktion nachvollziehbar.\n\nGitLab Duo CLI unterstützt darüber hinaus [benutzerdefinierte Instruktionsdateien](https://docs.gitlab.com/user/duo_agent_platform/customize/) – z. B. `chat-rules.md`, `AGENTS.md` und `SKILL.md` – die festlegen, welche Aufgaben, Ressourcen, Kontexte und Aktionen ein Agent ausführen darf. **Das ist das Prinzip der minimalen Rechtevergabe auf KI angewendet: Der Agent tut genau das, wozu er autorisiert wurde – und nichts darüber hinaus.**\n\nGitLab Duo CLI in Aktion:\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1179964611?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo CLI Beta Demo V1\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab Duo CLI ausprobieren\n\nDen Einstieg bietet ein [kostenloser Test der GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/).\n\nWer GitLab bereits im Free Tier nutzt, kann GitLab Duo Agent Platform durch [wenige einfache Schritte](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) aktivieren.\n\nBestehende GitLab-Premium- oder -Ultimate-Abonnenten können Duo CLI nutzen, indem sie [Duo Agent Platform aktivieren](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) – die benötigten GitLab Credits sind im jeweiligen Abonnement [bereits enthalten](https://docs.gitlab.com/subscriptions/gitlab_credits/#included-credits).\n",[723,10,27],"AI/ML",{"featured":32,"template":14,"slug":725},"gitlab-duo-cli",{"promotions":727},[728,742,754,766],{"id":729,"categories":730,"header":732,"text":733,"button":734,"image":739},"ai-modernization",[731],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":735,"config":736},"Get your AI maturity score",{"href":737,"dataGaName":738,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":740},{"src":741},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":743,"categories":744,"header":746,"text":733,"button":747,"image":751},"devops-modernization",[10,745],"devsecops","Are you just managing tools or shipping innovation?",{"text":748,"config":749},"Get your DevOps maturity score",{"href":750,"dataGaName":738,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":752},{"src":753},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":755,"categories":756,"header":758,"text":733,"button":759,"image":763},"security-modernization",[757],"security","Are you trading speed for security?",{"text":760,"config":761},"Get your security maturity score",{"href":762,"dataGaName":738,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":764},{"src":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":767,"paths":768,"header":771,"text":772,"button":773,"image":778},"github-azure-migration",[769,770],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":774,"config":775},"See how GitLab compares to GitHub",{"href":776,"dataGaName":777,"dataGaLocation":248},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":779},{"src":753},{"header":781,"blurb":782,"button":783,"secondaryButton":788},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":784,"config":785},"Kostenlosen Test starten",{"href":786,"dataGaName":55,"dataGaLocation":787},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":57,"config":789},{"href":59,"dataGaName":60,"dataGaLocation":787},1776449935176]