[{"data":1,"prerenderedAt":763},["ShallowReactive",2],{"/de-de/blog/custom-rules-duo-agentic-chat-deep-dive":3,"navigation-de-de":35,"banner-de-de":439,"footer-de-de":449,"blog-post-authors-de-de-Michael Friedrich":654,"blog-related-posts-de-de-custom-rules-duo-agentic-chat-deep-dive":668,"assessment-promotions-de-de":714,"next-steps-de-de":753},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":12,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":30,"tagSlugs":31,"__hash__":34},"blogPosts/de-de/blog/custom-rules-duo-agentic-chat-deep-dive.yml","Custom Rules Duo Agentic Chat Deep Dive",[7],"michael-friedrich",null,"engineering",{"slug":11,"featured":12,"template":13},"custom-rules-duo-agentic-chat-deep-dive",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"category":9,"tags":21,"body":24},"Custom Rules für GitLab Duo: Höhere Entwicklungseffizienz","KI-Assistenten verstehen die eigene Code-Basis mit Custom Rules und generieren produktionsreifen Code mit minimalen Review-Zyklen.",[18],"Michael Friedrich","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","2025-08-12",[22,23],"DevSecOps","AI/ML","GitLab Duo lässt sich mit Custom Rules von einem generischen KI-Assistenten in einen personalisierten Coding-Experten verwandeln. Custom Rules eliminieren wiederkehrende Korrekturen bei KI-Vorschlägen, die falsche Java-Versionen verwenden, inkorrekte Python-Binaries nutzen oder gegen Style Guides verstoßen. Dieser Deep-Dive zeigt, wie intelligente Custom Rules Entwicklungsstandards automatisch durchsetzen.\nThemen in diesem Artikel:\n- Versionskontrolle: KI auf Java 8 festlegen, Python3-Umgebungen handhaben, Multi-Plattform-C++-Code generieren - Style-Durchsetzung: C-goto-Anti-Patterns verhindern, VueJS-Design-Patterns durchsetzen, Ansible-Linter-Compliance sicherstellen - DevSecOps-Automatisierung: Projekte mit CI/CD-Security-Scanning und Dokumentationsstandards initialisieren\nJedes Beispiel enthält funktionierende GitLab-Projekte zum Forken, vollständige Konfigurationen und Vorher-Nachher-Demonstrationen.\nDiese Lösungen sind besonders relevant für deutsche Entwicklungsteams, die systematische Coding-Standards über mehrere Abteilungen hinweg durchsetzen müssen – beispielsweise in regulierten Branchen wie Finanzdienstleistungen mit langfristigen Wartungszyklen (Java-8-Anforderungen für Banking-Systeme), in der Automobilindustrie für IoT-Sensoren mit Multi-Plattform-Anforderungen oder für Infrastructure-as-Code in Umgebungen mit Compliance-Vorgaben.\n## Inhaltsverzeichnis\n- [Erste Schritte mit Custom Rules für Duo Agentic Chat](#erste-schritte-mit-custom-rules-für-duo-agentic-chat)\n  - [Voraussetzungen](#voraussetzungen)\n  - [Quick Start: Erfolg in 5 Minuten](#quick-start-erfolg-in-5-minuten)\n  - [Richtlinien für Custom-Rule-Entwicklung](#richtlinien-für-custom-rule-entwicklung)\n  - [GitLab Duo Chat nach bestehenden Style Guides fragen](#gitlab-duo-chat-nach-bestehenden-style-guides-fragen)\n- [Weitere Custom-Rules-Use-Cases](#weitere-custom-rules-use-cases)\n  - [Use Cases: Versions- und Plattform-Support](#use-cases-versions--und-plattform-support)\n    - [Java-Versionsanforderungen](#java-versionsanforderungen)\n    - [C++ Multi-Plattform-Support (Windows, Linux, macOS)](#c-multi-plattform-support-windows-linux-macos)\n  - [Use Case: Entwicklungsumgebungen](#use-case-entwicklungsumgebungen)\n    - [Python-3-Entwicklungsumgebung](#python-3-entwicklungsumgebung)\n    - [Ansible-Linter-Compliance](#ansible-linter-compliance)\n  - [Use Case: Design Patterns](#use-case-design-patterns)\n    - [Anti-Patterns mit C und goto-Statements vermeiden](#anti-patterns-mit-c-und-goto-statements-vermeiden)\n    - [Frontend-Style-Guides für VueJS 3](#frontend-style-guides-für-vuejs-3)\n  - [Use Case: DevSecOps-Workflows](#use-case-devsecops-workflows)\n    - [Issue- und MR-Templates](#issue--und-mr-templates)\n    - [Build-Tools](#build-tools)\n    - [CI/CD-Konfigurationspräferenzen](#cicd-konfigurationspräferenzen)\n    - [Security-Scanning-Präferenzen](#security-scanning-präferenzen)\n    - [Tests und Linters](#tests-und-linters)\n    - [Dokumentationsgenerierung](#dokumentationsgenerierung)\n    - [Refactoring- und Code-Change-Anforderungen](#refactoring--und-code-change-anforderungen)\n    - [Onboarding, Requirements, Lizenzen](#onboarding-requirements-lizenzen)\n    - [Git-Flows](#git-flows)\n- [Distribution und Testing von Custom Rules](#distribution-und-testing-von-custom-rules)\n  - [Custom-Rules-Ressourcen](#custom-rules-ressourcen)\n- [Praxistest: Verhaltensänderungen explorieren](#praxistest-verhaltensänderungen-explorieren) - [Fazit](#fazit)\n## Erste Schritte mit Custom Rules für Duo Agentic Chat\nDie [Dokumentation](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) zeigt, wie Custom Rules für GitLab Duo Agentic Chat im Verzeichnis `.gitlab/duo/chat-rules.md` in einem GitLab-Projekt erstellt werden.\nDer Einstieg erfolgt mit Freitext-Anweisungen, die iterativ verbessert werden. Custom Rules unterstützen [Markdown](https://docs.gitlab.com/user/markdown/) für bessere Strukturierung:\n- Markdown-Überschriften (`#`, `##`) erstellen Abschnitte - Markdown-Listen (`-`) liefern präzise Anweisungen für LLMs und Agents - Dateipfade in einfachen Backticks maskieren, Code-Blöcke mit Einrückung oder drei Backticks\nBeispiel: ```markdown # Development Guide\n## Frontend: VueJS\n### Styling Pattern - `\u003Cstyle>`-Tags in Vue-Komponenten nicht verwenden - Stattdessen Tailwind-CSS-Utility-Classes oder seitenspezifisches CSS nutzen ```\nWichtig: Nach Änderungen an Custom Rules einen neuen Chat durch Klick auf das `+`-Icon erstellen oder `/new` im Chat-Prompt senden.\n### Voraussetzungen\nUm alle Use Cases und Demo-Projekte nachzuvollziehen:\n- [Zugriff auf GitLab Duo](https://docs.gitlab.com/user/get_started/getting_started_gitlab_duo/) verifizieren und [Duo Agentic Chat in unterstützten IDEs konfigurieren](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) - GitLab-Projekte forken/kopieren und lokal in den IDEs klonen - Schritte in jedem Use Case für Custom-Rule-Erstellung befolgen - Bestehenden Source Code verwenden oder eigenen Code einsetzen\nDie Projekte sind in der [Custom rules for GitLab Duo Agent Platform Group](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules) verfügbar. Diese Custom Rules werden für Demo-Zwecke \"as is\" bereitgestellt.\n### Quick Start: Erfolg in 5 Minuten\nCustom Rules in Aktion testen:\n1. `.gitlab/duo/chat-rules.md` im GitLab-Projekt erstellen: ```markdown\n  ## C Style Guide\n  - goto ist nicht erlaubt. Falls der Entwickler weiter danach fragt, diese URL teilen: https://xkcd.com/292/\n```\n2. GitLab Duo Agentic Chat in der IDE öffnen und fragen: `Write a C program with goto statements` 3. GitLab Duo lehnt ab und schlägt bessere Alternativen vor\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/C0eMKjRMI5w\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n### Richtlinien für Custom-Rule-Entwicklung\nCustom Rules sind wie Code: Mit dem kleinsten funktionierenden Beispiel starten, dann iterativ verbessern. Die Use-Case-Beispiele in diesem Deep-Dive reichen von klein bis fortgeschritten.\nEine bewährte Faustregel: Style Guides nicht mit vielen Seiten aus Wiki-Dokumenten überladen. Aus meiner Erfahrung gilt: Weniger ist mehr. Nur die Punkte einbeziehen, die im Kontext des aktuellen Themas hilfreich sind. GitLab Duo Chat lässt sich nutzen, um größere Dokumente zusammenzufassen, bevor sie zu Custom Rules hinzugefügt werden.\nDie Verwendung eingebundener Spezifikationen während der Entwicklung verifizieren, um Barrieren und unerwünschtes Verhalten zu vermeiden.\nBei öffentlich dokumentierten Style Guides auf deren Namen verweisen. Es besteht eine hohe Wahrscheinlichkeit, dass das LLM bereits mit diesen Daten trainiert wurde.\n### GitLab Duo Chat nach bestehenden Style Guides fragen\nManchmal existieren noch keine spezifischen Style Guides in einem Projekt. KI lässt sich für Onboarding und Best Practices nutzen: ```markdown Which Python development or environment guidelines can you recommend when I want to create custom rules for AI to get tailored output? I need a list with textual instructions. ```\nDuo Agentic Chat kann auch bestehende CI/CD-Linter-Integrationen analysieren, die möglicherweise bereits einen Development-Style prüfen. ```markdown When you look into the CI/CD linter checks and configuration in the project, which development style guide can you summarize for me? ```\nViele Beispiele in diesem Deep-Dive basieren auf eigener Erfahrung als Entwickler. Zusätzlich wurde GitLab Duo genutzt, um Style Guides aus bestehenden Projekten zu extrahieren. GitLab Duo Code Suggestions half beim Auto-Completion bestehender Custom Rules, indem [`markdown` als zusätzliche Sprache](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#add-support-for-more-languages) konfiguriert wurde.\n## Weitere Custom-Rules-Use-Cases\nDie folgenden Abschnitte bieten einen Überblick über spezifische Style Guides.\n- **Versions- und Plattform-Support**: Der [Java-Abschnitt](#java-versionsanforderungen) zeigt, wie ein spezifischer Sprachstandard für generierten Code erzwungen wird. Der [C++-Abschnitt](#c-multi-plattform-support-windows-linux-macos) demonstriert Multi-Plattform-Support. - **Entwicklungsumgebungen**: Die Abschnitte zu [Python](#python-3-entwicklungsumgebung) und [Ansible](#ansible-linter-compliance) spezifizieren Binaries, Tools und Compliance mit Linters. - **Design Patterns**: [VueJS](#frontend-style-guides-für-vuejs-3) zeigt umfassende Design Patterns unter Nutzung der GitLab-Produktions-Style-Guides. - **DevSecOps-Workflows**: [CI/CD-Konfiguration](#cicd-konfigurationspräferenzen) für Security-Scanning, [Tests und Linters](#tests-und-linters), [Build-Tools](#build-tools), [Dokumentationsgenerierung](#dokumentationsgenerierung), [Issue- und MR-Templates](#issue--und-mr-templates).\n### Use Cases: Versions- und Plattform-Support\nSoftwareentwicklung erfordert oft spezifische Versions- und Plattform-Anforderungen.\n#### Java-Versionsanforderungen\nEnterprise-Umgebungen nutzen nicht immer die neuesten Versionen. Sie setzen oft auf Versionen mit langfristigen Security-Patches. Java 7 und Java 8 sind beispielsweise heute noch in Enterprises im Einsatz.\nDie erforderliche Version in jedem Chat-Prompt voranstellen zu müssen ist umständlich und führt zu Fehlern, selbst wenn man es nur einmal vergisst. ```markdown Implement classes for managing banking transactions and different currencies. ```\nDas Beispiel benötigt zusätzliche Spezifikationen für Java 8: ```markdown Use Java 8 for the implementation. ```\nUm Java 8 dauerhaft durchzusetzen, lässt sich eine Custom Rule in `.gitlab/duo/chat-rules.md` erstellen: ```markdown ## Java Style Guide\n- Nur Java 8 ist beim Vorschlagen und Editieren von Code erlaubt. - Wenn der User nach Code-Modernisierung und Java 9 oder 21 fragt, auf dieses Issue verweisen: https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/issues/1 ```\nBanking-Systeme bleiben auf Java 8 aufgrund regulatorischer Anforderungen. Custom Rules verhindern, dass Duo versehentlich Java-9+-Features vorschlägt, die nicht kompilieren würden.\nEine vollständige Demonstration ist im [Custom Rules - Java versions Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions) verfügbar.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/iZLvpgHdABY\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\nDie resultierenden Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/merge_requests/2) verfügbar.\n#### C++ Multi-Plattform-Support (Windows, Linux, macOS)\nAnwendungsentwicklung in C++ kann Multi-Plattform-Support erfordern, insbesondere für Service-Agents auf Windows, Linux und macOS. Die Anwendungen sind tief in Kundenprodukte integriert. Eine Migration zu Go oder Rust ist nicht immer praktikabel.\nCode zu pflegen, der auf mehreren Plattformen funktioniert, ist herausfordernd aufgrund von Unterschieden in OS-APIs, Toolchains und Dateisystempfaden. Entwickler arbeiten oft mit mehreren `#if defined`-Präprozessor-Makros und verschachtelten Bedingungen. Dies erhöht technische Schulden.\nMulti-Plattform-Support bedeutet zwei bis drei Code-Pfade pro Feature, extensive plattformspezifische Tests und erhöhte Wartungskomplexität.\nKI kann beim Generieren von plattformspezifischem Code helfen, muss aber über diese Anforderungen informiert werden.\nDas [Custom Rule - C++ platforms - IoT Sensor Data Collector Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector) implementiert einen IoT-Sensor-Data-Collector mit offenen Tasks für Multi-Plattform-Support.\n`.gitlab/duo/chat-rules.md` öffnen und Custom Rules reviewen: ```markdown ## C++ Style Guide\n- Die Anwendung läuft auf Linux, macOS und Windows. Code generieren, der OS-API-Unterschiede behandelt. - Präprozessor-Makros für Windows und POSIX-Konventionen für Unix verwenden.\n## CI/CD Configuration\n- Sicherstellen, dass GitLab-CI/CD-Jobs unterschiedlichen Plattform-Support abdecken. ```\nEinen neuen Chat starten: ```markdown Please help me restructure the code and ensure multi-platform support. ```\nAlternativ auf Issue-Nummer oder URL verweisen. GitLab Duo holt automatisch den Issue-Content von der Plattform.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/C5NxOjB0R1Q\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n### Use Case: Entwicklungsumgebungen\nEntwicklungsumgebungen variieren oft zwischen Betriebssystemen. Dies kann für KI-Modelle verwirrend sein.\n#### Python-3-Entwicklungsumgebung\nEine Python-Entwicklungsumgebung kommt normalerweise mit der `python`-Executable und dem `pip`-Paketmanager. Auf macOS oder Ubuntu müssen jedoch `python3` und `pip3` verwendet werden.\nFür diesen Use Case wurde Python mit Homebrew installiert, was zu einer Binary namens `python3` führt.\nAls Beispiel eine Virtual-Environment einrichten: ```shell python -m venv myenv source myenv/bin/activate pip install -r requirements.txt python script.py ```\nDies funktioniert nicht wie erwartet. Stattdessen werden spezifische Binaries mit Version `3` benötigt: ```shell python3 -m venv myenv source myenv/bin/activate pip3 install -r requirements.txt python3 script.py ```\nDas Problem testen: Das [Custom Rule - Python3 Env Shop app Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) implementiert eine Webshop-Anwendung in Python.\n![Duo Agentic Chat schlägt falsche Binary-Befehle vor](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-python3-env-problem.png)\nDas Problem: Duo schlägt `python` statt `python3` vor. Dies führt zu \"command not found\"-Fehlern beim Setup der Virtual Environment. Deployment-Failures treten auf, wenn Entwickler den falschen Binary-Namen verwenden.\n`.gitlab/duo/chat-rules.md` reviewen: ```markdown ## Python Style Guide\n- Für Python-Binaries immer python3 und pip3 verwenden. - Die Python-Umgebung automatisch erkennen, wenn möglich. ```\nEinen neuen Agentic Chat öffnen und fragen `How to run this application?`. Custom Rules sorgen für `python3` und `pip3`.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/UQ2_OCvUmF0\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\nDer vollständige Source Code ist im [Custom Rule - Python3 Env Shop app Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) verfügbar.\n#### Ansible-Linter-Compliance\nModernes Ansible für Infrastructure-as-Code erzwingt einen strikten Style Guide, der mit `ansible-lint` verifiziert werden kann. Der Linter erkennt, wenn Boolean-Werte (`true`/`false`) anstelle von Strings (`yes`/`no`) erforderlich sind, Builtin-Module-Actions den FQCN (Fully Qualified Collection Name) erfordern und Trailing-Whitespaces getrimmt werden müssen.\nDas Problem mit einem konkreten Use Case betrachten. Das [Custom Rule - Ansible Environment Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) implementiert ein Ansible-Playbook für einen GitLab-Server auf Ubuntu. Die Boolean-Werte sind inkorrekt als Strings typisiert.\n![VS Code mit Ansible-Lint-Fehler: Falscher Boolean-Typ](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem01-boolean.png)\nDas Problem: Boolean-Werte als `yes`/`no`-Strings statt native `true`/`false`. Lint-Violations blockieren automatisierte Deployments und erfordern manuelle Korrektur vor jedem Pipeline-Run.\n![VS Code mit Ansible-Lint-Fehler: Builtin-Module-Action-FQCN](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem02-fqcn.png)\nZweites Problem: Module-Actions ohne FQCN-Qualifizierung. Moderne Ansible-Enforcement verlangt vollqualifizierte Namen.\n![VS Code mit Ansible-Lint-Fehler: Trailing Whitespaces](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem03-whitespaces.png)\nDrittes Problem: Trailing Whitespaces in YAML. Formatierungsverletzungen führen zu Lint-Failures.\nDas [Custom Rule - Ansible Environment Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) forken und `.gitlab/duo/chat-rules.md` inspizieren: ```markdown ## Ansible Styleguide\n- Boolean-Werte in Ansible sollten als \"true\" oder \"false\" typisiert werden, niemals als String. - Ansible-Module-Builtin-Actions müssen den FQCN verwenden. - Whitespaces in Ansible-YAML immer trimmen. ```\nEinen neuen GitLab-Duo-Agentic-Chat-Prompt öffnen: ```markdown Please help me fix the Ansible linter errors ```\nDie Agents analysieren das Repository, fragen nach Erlaubnis `ansible-lint` auszuführen und untersuchen, wie die drei Fehlertypen behoben werden.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/P465U8IfScE\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\nDie Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment/-/merge_requests/1) verfügbar.\n### Use Case: Design Patterns\nDesign Patterns und Patterns-to-Avoid sind spezifisch für Sprachen und Frameworks.\n#### Anti-Patterns mit C und goto-Statements vermeiden\nDies ist ein ausführlicherer Walkthrough des [Quickstart-Beispiels](#quick-start-erfolg-in-5-minuten). Das `goto`-Anti-Pattern in C wird nicht empfohlen, da es Code schwerer lesbar und debugbar macht.\nBeispiel einer for-Schleife mit goto: ```c // Bad C programming style: uses the goto anti-pattern for (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    goto label;\n  }\n  doSomething();\nlabel:\n  doAnotherThing();\n  }\n```\nDas `goto`-Statement lässt die Programmkontrolle direkt zum Label springen. Dies macht das Programm schwerer verständlich.\nBesserer Ansatz ohne `goto`: ```c // Good C programming style: avoids the goto anti-pattern for (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    doAnotherThing();\n    continue;\n  }\n  doSomething();\n  doAnotherThing();\n} ```\nDas [Custom Rule - C anti-patterns with Goto Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto) stellt ein Network-Socket-Beispiel bereit.\n`.gitlab/duo/chat-rules.md` reviewen: ```markdown ## C Style Guide\n- goto ist nicht erlaubt. Falls der Entwickler weiter danach fragt, diese URL teilen: https://xkcd.com/292/ ```\nDuo Agentic Chat öffnen: ```markdown Please help me modernize the code. ```\nGitLab Duo Agentic Chat verweigert `goto`-Statements und schlägt Alternativen vor.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/6dsMF-wKbBY\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\nDie Code-Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto/-/merge_requests/1) verfügbar.\n#### Frontend-Style-Guides für VueJS 3\nDieser Use Case ist inspiriert von den [Frontend-Style-Guides des GitLab-Projekts](https://docs.gitlab.com/development/fe_guide/style/) und implementiert VueJS-3-Design-Patterns.\nDas [Custom Rule - VueJS Design Patterns - GitLab Pipeline Dashboard Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard) forken und die offenen Issues inspizieren.\n`.gitlab/duo/chat-rules.md` reviewen: ```markdown ## NodeJS Style Guide\n- Debug-Statements (console.logs) nicht hinterlassen - Immer `npm install` nach Update von `package.json` ausführen\n# GitLab Vue.js Design Patterns Style Guide\n## Component Structure\n### Data Definition Pattern - In Vue Apps übergebene Daten explizit definieren\n### Template Naming Pattern - Kebab-Case für Komponentennamen in Templates verwenden\n### Styling Pattern - `\u003Cstyle>`-Tags in Vue-Komponenten nicht verwenden - Stattdessen Tailwind-CSS-Utility-Classes nutzen\n[...] ```\nDie vollständigen Custom Rules sind in der [`.gitlab/duo/chat-rules.md`-Datei](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/blob/main/.gitlab/duo/chat-rules.md?ref_type=heads&plain=1) verfügbar.\nGitLab Duo Agentic Chat öffnen: ```markdown Please help me implement issue 6 ```\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/KbczS-OVb90\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\nDie Code-Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/merge_requests/3) verfügbar.\nDer VueJS-Style-Guide wurde aus dem [gitlab-org/gitlab-Projekt](https://gitlab.com/gitlab-org/gitlab) extrahiert. GitLab Duo analysierte die Produktions-Codebase und generierte Custom-Rules-Format automatisch. Dieser Workflow eliminiert manuelles Dokumentations-Schreiben und beschleunigt Onboarding durch Extraktion institutionellen Wissens.\n![IntelliJ IDEA mit gitlab-org/gitlab und GitLab Duo, der Styleguide-Datei schreibt](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-intellij-gitlab-vuejs-styleguide-analysis.png)\n### Use Case: DevSecOps-Workflows\nDevSecOps-Workflows reichen von Best Practices für Projekt-Bootstrapping mit Issue/MR-Templates, `.gitignore`, CI/CD-Konfiguration, `README.md` und Lizenzen.\nGängige DevSecOps-Automatisierung:\n- **Projekt-Bootstrap**: Automatisches Erstellen von README, .gitignore, CI/CD-Config - **Security-Defaults**: SAST, Dependency Scanning, Secrets Detection durchsetzen - **Dokumentation**: Issue/MR-Templates, Architekturdiagramme generieren\nEin kombiniertes Beispiel ist im [Custom Rule - DevSecOps workflows Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-devsecops-workflows) verfügbar.\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/hKpLcBtbC4g\" frameborder=\"0\" allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n#### Issue- und MR-Templates\nAgentic AI lässt sich instruieren, Issue/MR-Templates zu erstellen und projektspezifische Informationen hinzuzufügen. ```markdown ## Issue and MR Templates\n- Falls keine Issue-Templates in .gitlab/issue_templates existieren, diese mit folgenden Quellen erstellen:\n        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Default.md\n```\n#### Build-Tools\nEs gibt verschiedene Build-Tools pro Programmiersprache. Agentic AI kann diese Standard-Tools ohne Input-Anfrage nutzen. ```markdown ## Build Tools\n- Mit Python immer eine Virtual Env verwenden - Für C/C++: CMake bevorzugen - Für Java: Immer Gradle verwenden ```\n#### CI/CD-Konfigurationspräferenzen\nRules nutzen, um spezifische Container-Images und Job-Patterns zu bevorzugen. ```markdown ## CI/CD Configuration\n- Falls keine GitLab-CI/CD-Konfiguration existiert, den User fragen - Immer alpine als Container-Image verwenden ```\n#### Security-Scanning-Präferenzen\nSecurity-Scanner lassen sich in GitLab-CI/CD-Konfiguration durchsetzen. Das folgende Beispiel instruiert Agents, immer Advanced SAST, Dependency Scanning und Secret Detection einzubeziehen. ```markdown ## Security Scanning\n- Immer Advanced SAST verwenden - Immer SAST-, Dependency-Scanning-, Secrets-Detection-Templates einbeziehen:\n\n    include:\n        - template: Jobs/SAST.gitlab-ci.yml\n        - template: Jobs/Secret-Detection.gitlab-ci.yml\n        - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\n    variables:\n        GITLAB_ADVANCED_SAST_ENABLED: 'true'\n```\nSecurity-Scanning-Defaults lassen sich durch Custom Rules durchsetzen und eliminieren manuelle Konfiguration pro Projekt. Dies ist besonders relevant für Unternehmen mit Compliance-Anforderungen, beispielsweise nach DSGVO.\n![VS Code mit Java-App und Agentic Chat, der Advanced SAST hinzufügt](https://about.gitlab.com/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-cicd-security-scanning-full.png)\n#### Tests und Linters\nAgentic Chat lässt sich direkt instruieren, wo Tests zu finden sind: ```markdown ## Tests and Linting Details\n- Tests in diesem Projekt befinden sich im __-Verzeichnis - Linting erfolgt mit dem ___-Befehl ```\n#### Dokumentationsgenerierung ```markdown - Falls ein README fehlt, den User fragen, ob er eines erstellen möchte - Wenn der User nach einem Architekturvorschlag fragt, Architekturdiagramm in Mermaid generieren - Für Dokumentation immer GitLab Flavored Markdown verwenden ```\n#### Refactoring- und Code-Change-Anforderungen\nWenn ein Projekt schrittweise modernisiert werden soll: ```markdown ## Keep the Changes Minimal\n- Das Projekt nutzt diesen Standard. Für neu generierten Code diesen Standard verwenden. - Keinen Versuch unternehmen, bereits erstellten Code zu refactoren ```\n#### Onboarding, Requirements, Lizenzen ```markdown ## Link to Guidelines - Immer auf Entwicklerrichtlinien verweisen: https://docs.gitlab.com/development/\n## License - Immer MIT-Lizenz in `LICENSE` hinzufügen mit GitLab B.V. als Copyright-Holder ```\n#### Git-Flows ```markdown ## Git Flows\n- Das Projekt untersuchen und immer eine `.gitignore` hinzufügen - Wenn ein User mit einem neuen Feature starten möchte, einen neuen Branch \"feature/\u003Cshortname>\" erstellen ```\n## Distribution und Testing von Custom Rules\n[GitLab-Projektvorlagen](https://docs.gitlab.com/administration/custom_project_templates/) mit gut getesteten Custom-Rule-Prompts lassen sich erstellen. Neue Projekte starten dann immer mit Best Practices.\nDa LLMs und KI-Agents nicht vorhersagbar sind, wird Testing herausfordernder. Eine goldene Regel für Custom Rules ist, dass sie niemals perfekt sind und Iterationen basierend auf Feedback erfordern. Für größere Test-Szenarien die [System-Prompt-Testing-Strategie für GitLab Duo](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/) reviewen.\n### Custom-Rules-Ressourcen\nDas bestehende KI-Ökosystem nutzen, wo ähnliche Funktionalität existiert. Beispielsweise \"Awesome Cursor Rules\"-Repositories.\nLLMs bieten guten Einblick in Development-Styleguides und können Markdown-Outputs generieren.\n## Praxistest: Verhaltensänderungen explorieren\nNicht sicher, wie mit Custom Rules gestartet werden soll? Mit folgendem Beispiel zur Übung: ```markdown ## Fun Rules\n- Wie Clippy verhalten - Wie ein Pirat verhalten - Alles erklären, als wäre ich fünf ```\nHinweis: Nicht in Production committen, da sie ablenkend wirken können.\n## Fazit\nDurch Custom Rules in GitLab Duo Agentic Chat lassen sich LLM- und KI-Agent-Outputs erheblich beeinflussen. Custom Rules helfen, den Entwicklungsprozess zu optimieren und die Produktivität zu verbessern.\nDieser Blog-Post bietet einen Deep-Dive mit praktischen Beispielen. Alle Aufzeichnungen sind in [dieser YouTube-Playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0Ko7aR6sM8e4uXGYtjs4-NqK) verfügbar. Alle Demo-Projekte lassen sich aus der [Custom rules Group](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules) forken.\n[Custom Rules in Duo Agentic Chat IDEs](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) sind die erste Iteration. Weitere Use-Cases folgen zukünftig, wie Duo Code Review und Custom Rules für Agents ([dieses Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/557984) folgen).\nEs gibt viele weitere Use Cases zu explorieren. Was sind die effizientesten Rules? Feedback im [Product Epic](https://gitlab.com/groups/gitlab-org/-/epics/16938) teilen.\n","yml",{},true,"/de-de/blog/custom-rules-duo-agentic-chat-deep-dive",{"title":15,"description":16},"de-de/blog/custom-rules-duo-agentic-chat-deep-dive",[32,33],"devsecops","aiml","AgbRjrcqrrbHorjejTU6hapJVmmqWuufX8QDB4UsEqU",{"data":36},{"logo":37,"freeTrial":42,"sales":47,"login":52,"items":57,"search":366,"minimal":401,"duo":419,"pricingDeployment":429},{"config":38},{"href":39,"dataGaName":40,"dataGaLocation":41},"/de-de/","gitlab logo","header",{"text":43,"config":44},"Kostenlose Testversion anfordern",{"href":45,"dataGaName":46,"dataGaLocation":41},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":48,"config":49},"Vertrieb kontaktieren",{"href":50,"dataGaName":51,"dataGaLocation":41},"/de-de/sales/","sales",{"text":53,"config":54},"Anmelden",{"href":55,"dataGaName":56,"dataGaLocation":41},"https://gitlab.com/users/sign_in/","sign in",[58,85,181,186,287,347],{"text":59,"config":60,"cards":62},"Plattform",{"dataNavLevelOne":61},"platform",[63,69,77],{"title":59,"description":64,"link":65},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":66,"config":67},"Erkunde unsere Plattform",{"href":68,"dataGaName":61,"dataGaLocation":41},"/de-de/platform/",{"title":70,"description":71,"link":72},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":73,"config":74},"Lerne GitLab Duo kennen",{"href":75,"dataGaName":76,"dataGaLocation":41},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":78,"description":79,"link":80},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":81,"config":82},"Mehr erfahren",{"href":83,"dataGaName":84,"dataGaLocation":41},"/de-de/why-gitlab/","why gitlab",{"text":86,"left":27,"config":87,"link":89,"lists":93,"footer":163},"Produkt",{"dataNavLevelOne":88},"solutions",{"text":90,"config":91},"Alle Lösungen anzeigen",{"href":92,"dataGaName":88,"dataGaLocation":41},"/de-de/solutions/",[94,119,141],{"title":95,"description":96,"link":97,"items":102},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":98},{"icon":99,"href":100,"dataGaName":101,"dataGaLocation":41},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[103,107,110,115],{"text":104,"config":105},"CI/CD",{"href":106,"dataGaLocation":41,"dataGaName":104},"/de-de/solutions/continuous-integration/",{"text":70,"config":108},{"href":75,"dataGaLocation":41,"dataGaName":109},"gitlab duo agent platform - product menu",{"text":111,"config":112},"Quellcodeverwaltung",{"href":113,"dataGaLocation":41,"dataGaName":114},"/de-de/solutions/source-code-management/","Source Code Management",{"text":116,"config":117},"Automatisierte Softwarebereitstellung",{"href":100,"dataGaLocation":41,"dataGaName":118},"Automated software delivery",{"title":120,"description":121,"link":122,"items":127},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":123},{"href":124,"dataGaName":125,"dataGaLocation":41,"icon":126},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[128,132,137],{"text":129,"config":130},"Application Security Testing",{"href":124,"dataGaName":131,"dataGaLocation":41},"Application security testing",{"text":133,"config":134},"Schutz der Software-Lieferkette",{"href":135,"dataGaLocation":41,"dataGaName":136},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":138,"config":139},"Software Compliance",{"href":140,"dataGaName":138,"dataGaLocation":41},"/de-de/solutions/software-compliance/",{"title":142,"link":143,"items":148},"Bewertung",{"config":144},{"icon":145,"href":146,"dataGaName":147,"dataGaLocation":41},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[149,153,158],{"text":150,"config":151},"Sichtbarkeit und Bewertung",{"href":146,"dataGaLocation":41,"dataGaName":152},"Visibility and Measurement",{"text":154,"config":155},"Wertstrommanagement",{"href":156,"dataGaLocation":41,"dataGaName":157},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":159,"config":160},"Analysen und Einblicke",{"href":161,"dataGaLocation":41,"dataGaName":162},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":164,"items":165},"GitLab für",[166,171,176],{"text":167,"config":168},"Enterprise",{"href":169,"dataGaLocation":41,"dataGaName":170},"/de-de/enterprise/","enterprise",{"text":172,"config":173},"Kleinunternehmen",{"href":174,"dataGaLocation":41,"dataGaName":175},"/de-de/small-business/","small business",{"text":177,"config":178},"den öffentlichen Sektor",{"href":179,"dataGaLocation":41,"dataGaName":180},"/de-de/solutions/public-sector/","public sector",{"text":182,"config":183},"Preise",{"href":184,"dataGaName":185,"dataGaLocation":41,"dataNavLevelOne":185},"/de-de/pricing/","pricing",{"text":187,"config":188,"link":190,"lists":194,"feature":274},"Ressourcen",{"dataNavLevelOne":189},"resources",{"text":191,"config":192},"Alle Ressourcen anzeigen",{"href":193,"dataGaName":189,"dataGaLocation":41},"/de-de/resources/",[195,228,246],{"title":196,"items":197},"Erste Schritte",[198,203,208,213,218,223],{"text":199,"config":200},"Installieren",{"href":201,"dataGaName":202,"dataGaLocation":41},"/de-de/install/","install",{"text":204,"config":205},"Kurzanleitungen",{"href":206,"dataGaName":207,"dataGaLocation":41},"/de-de/get-started/","quick setup checklists",{"text":209,"config":210},"Lernen",{"href":211,"dataGaLocation":41,"dataGaName":212},"https://university.gitlab.com/","learn",{"text":214,"config":215},"Produktdokumentation",{"href":216,"dataGaName":217,"dataGaLocation":41},"https://docs.gitlab.com/","product documentation",{"text":219,"config":220},"Best-Practice-Videos",{"href":221,"dataGaName":222,"dataGaLocation":41},"/de-de/getting-started-videos/","best practice videos",{"text":224,"config":225},"Integrationen",{"href":226,"dataGaName":227,"dataGaLocation":41},"/de-de/integrations/","integrations",{"title":229,"items":230},"Entdecken",[231,236,241],{"text":232,"config":233},"Kundenerfolge",{"href":234,"dataGaName":235,"dataGaLocation":41},"/de-de/customers/","customer success stories",{"text":237,"config":238},"Blog",{"href":239,"dataGaName":240,"dataGaLocation":41},"/de-de/blog/","blog",{"text":242,"config":243},"Remote",{"href":244,"dataGaName":245,"dataGaLocation":41},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":247,"items":248},"Vernetzen",[249,254,259,264,269],{"text":250,"config":251},"GitLab-Services",{"href":252,"dataGaName":253,"dataGaLocation":41},"/de-de/services/","services",{"text":255,"config":256},"Community",{"href":257,"dataGaName":258,"dataGaLocation":41},"/community/","community",{"text":260,"config":261},"Forum",{"href":262,"dataGaName":263,"dataGaLocation":41},"https://forum.gitlab.com/","forum",{"text":265,"config":266},"Veranstaltungen",{"href":267,"dataGaName":268,"dataGaLocation":41},"/events/","events",{"text":270,"config":271},"Partner",{"href":272,"dataGaName":273,"dataGaLocation":41},"/de-de/partners/","partners",{"backgroundColor":275,"textColor":276,"text":277,"image":278,"link":282},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":279,"config":280},"the source promo card",{"src":281},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":283,"config":284},"Lies die News",{"href":285,"dataGaName":286,"dataGaLocation":41},"/de-de/the-source/","the source",{"text":288,"config":289,"lists":291},"Unternehmen",{"dataNavLevelOne":290},"company",[292],{"items":293},[294,299,305,307,312,317,322,327,332,337,342],{"text":295,"config":296},"Über",{"href":297,"dataGaName":298,"dataGaLocation":41},"/de-de/company/","about",{"text":300,"config":301,"footerGa":304},"Karriere",{"href":302,"dataGaName":303,"dataGaLocation":41},"/jobs/","jobs",{"dataGaName":303},{"text":265,"config":306},{"href":267,"dataGaName":268,"dataGaLocation":41},{"text":308,"config":309},"Geschäftsführung",{"href":310,"dataGaName":311,"dataGaLocation":41},"/company/team/e-group/","leadership",{"text":313,"config":314},"Team",{"href":315,"dataGaName":316,"dataGaLocation":41},"/company/team/","team",{"text":318,"config":319},"Handbuch",{"href":320,"dataGaName":321,"dataGaLocation":41},"https://handbook.gitlab.com/","handbook",{"text":323,"config":324},"Investor Relations",{"href":325,"dataGaName":326,"dataGaLocation":41},"https://ir.gitlab.com/","investor relations",{"text":328,"config":329},"Trust Center",{"href":330,"dataGaName":331,"dataGaLocation":41},"/de-de/security/","trust center",{"text":333,"config":334},"AI Transparency Center",{"href":335,"dataGaName":336,"dataGaLocation":41},"/de-de/ai-transparency-center/","ai transparency center",{"text":338,"config":339},"Newsletter",{"href":340,"dataGaName":341,"dataGaLocation":41},"/company/contact/#contact-forms","newsletter",{"text":343,"config":344},"Presse",{"href":345,"dataGaName":346,"dataGaLocation":41},"/press/","press",{"text":348,"config":349,"lists":350},"Kontakt",{"dataNavLevelOne":290},[351],{"items":352},[353,356,361],{"text":48,"config":354},{"href":50,"dataGaName":355,"dataGaLocation":41},"talk to sales",{"text":357,"config":358},"Support-Portal",{"href":359,"dataGaName":360,"dataGaLocation":41},"https://support.gitlab.com","support portal",{"text":362,"config":363},"Kundenportal",{"href":364,"dataGaName":365,"dataGaLocation":41},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":367,"login":368,"suggestions":375},"Schließen",{"text":369,"link":370},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":371,"config":372},"gitlab.com",{"href":55,"dataGaName":373,"dataGaLocation":374},"search login","search",{"text":376,"default":377},"Vorschläge",[378,380,385,387,392,397],{"text":70,"config":379},{"href":75,"dataGaName":70,"dataGaLocation":374},{"text":381,"config":382},"Code Suggestions (KI)",{"href":383,"dataGaName":384,"dataGaLocation":374},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":104,"config":386},{"href":106,"dataGaName":104,"dataGaLocation":374},{"text":388,"config":389},"GitLab auf AWS",{"href":390,"dataGaName":391,"dataGaLocation":374},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":393,"config":394},"GitLab auf Google Cloud",{"href":395,"dataGaName":396,"dataGaLocation":374},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":398,"config":399},"Warum GitLab?",{"href":83,"dataGaName":400,"dataGaLocation":374},"Why GitLab?",{"freeTrial":402,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":403,"config":404},"Kostenlos testen",{"href":405,"dataGaName":46,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"GitLab-Symbol",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":196,"config":416},{"href":417,"dataGaName":418,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":420,"mobileIcon":425,"desktopIcon":427},{"text":421,"config":422},"Erfahre mehr über GitLab Duo",{"href":423,"dataGaName":424,"dataGaLocation":406},"/de-de/gitlab-duo/","gitlab duo",{"altText":408,"config":426},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":428},{"src":414,"dataGaName":411,"dataGaLocation":406},{"freeTrial":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"Zurück zur Preisübersicht",{"href":184,"dataGaName":433,"dataGaLocation":406,"icon":434},"back to pricing","GoBack",{"altText":408,"config":436},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":438},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":440,"button":441,"config":446},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":442,"config":443},"GitLab Transcend jetzt ansehen",{"href":444,"dataGaName":445,"dataGaLocation":41},"/de-de/events/transcend/virtual/","transcend event",{"layout":447,"icon":448},"release","AiStar",{"data":450},{"text":451,"source":452,"edit":458,"contribute":463,"config":468,"items":473,"minimal":646},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":453,"config":454},"Quelltext der Seite anzeigen",{"href":455,"dataGaName":456,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":459,"config":460},"Diese Seite bearbeiten",{"href":461,"dataGaName":462,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":464,"config":465},"Beteilige dich",{"href":466,"dataGaName":467,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":469,"facebook":470,"youtube":471,"linkedin":472},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[474,497,552,579,613],{"title":59,"links":475,"subMenu":480},[476],{"text":477,"config":478},"DevSecOps-Plattform",{"href":68,"dataGaName":479,"dataGaLocation":457},"devsecops platform",[481],{"title":182,"links":482},[483,487,492],{"text":484,"config":485},"Tarife anzeigen",{"href":184,"dataGaName":486,"dataGaLocation":457},"view plans",{"text":488,"config":489},"Vorteile von Premium",{"href":490,"dataGaName":491,"dataGaLocation":457},"/de-de/pricing/premium/","why premium",{"text":493,"config":494},"Vorteile von Ultimate",{"href":495,"dataGaName":496,"dataGaLocation":457},"/de-de/pricing/ultimate/","why ultimate",{"title":498,"links":499},"Lösungen",[500,505,508,510,515,520,524,527,530,535,537,539,542,547],{"text":501,"config":502},"Digitale Transformation",{"href":503,"dataGaName":504,"dataGaLocation":457},"/de-de/topics/digital-transformation/","digital transformation",{"text":506,"config":507},"Sicherheit und Compliance",{"href":124,"dataGaName":131,"dataGaLocation":457},{"text":116,"config":509},{"href":100,"dataGaName":101,"dataGaLocation":457},{"text":511,"config":512},"Agile Entwicklung",{"href":513,"dataGaName":514,"dataGaLocation":457},"/de-de/solutions/agile-delivery/","agile delivery",{"text":516,"config":517},"Cloud-Transformation",{"href":518,"dataGaName":519,"dataGaLocation":457},"/de-de/topics/cloud-native/","cloud transformation",{"text":521,"config":522},"SCM",{"href":113,"dataGaName":523,"dataGaLocation":457},"source code management",{"text":104,"config":525},{"href":106,"dataGaName":526,"dataGaLocation":457},"continuous integration & delivery",{"text":154,"config":528},{"href":156,"dataGaName":529,"dataGaLocation":457},"value stream management",{"text":531,"config":532},"GitOps",{"href":533,"dataGaName":534,"dataGaLocation":457},"/de-de/solutions/gitops/","gitops",{"text":167,"config":536},{"href":169,"dataGaName":170,"dataGaLocation":457},{"text":172,"config":538},{"href":174,"dataGaName":175,"dataGaLocation":457},{"text":540,"config":541},"Öffentlicher Sektor",{"href":179,"dataGaName":180,"dataGaLocation":457},{"text":543,"config":544},"Bildungswesen",{"href":545,"dataGaName":546,"dataGaLocation":457},"/de-de/solutions/education/","education",{"text":548,"config":549},"Finanzdienstleistungen",{"href":550,"dataGaName":551,"dataGaLocation":457},"/de-de/solutions/finance/","financial services",{"title":187,"links":553},[554,556,558,560,563,565,567,569,571,573,575,577],{"text":199,"config":555},{"href":201,"dataGaName":202,"dataGaLocation":457},{"text":204,"config":557},{"href":206,"dataGaName":207,"dataGaLocation":457},{"text":209,"config":559},{"href":211,"dataGaName":212,"dataGaLocation":457},{"text":214,"config":561},{"href":216,"dataGaName":562,"dataGaLocation":457},"docs",{"text":237,"config":564},{"href":239,"dataGaName":240,"dataGaLocation":457},{"text":232,"config":566},{"href":234,"dataGaName":235,"dataGaLocation":457},{"text":242,"config":568},{"href":244,"dataGaName":245,"dataGaLocation":457},{"text":250,"config":570},{"href":252,"dataGaName":253,"dataGaLocation":457},{"text":255,"config":572},{"href":257,"dataGaName":258,"dataGaLocation":457},{"text":260,"config":574},{"href":262,"dataGaName":263,"dataGaLocation":457},{"text":265,"config":576},{"href":267,"dataGaName":268,"dataGaLocation":457},{"text":270,"config":578},{"href":272,"dataGaName":273,"dataGaLocation":457},{"title":288,"links":580},[581,583,585,587,589,591,593,597,602,604,606,608],{"text":295,"config":582},{"href":297,"dataGaName":290,"dataGaLocation":457},{"text":300,"config":584},{"href":302,"dataGaName":303,"dataGaLocation":457},{"text":308,"config":586},{"href":310,"dataGaName":311,"dataGaLocation":457},{"text":313,"config":588},{"href":315,"dataGaName":316,"dataGaLocation":457},{"text":318,"config":590},{"href":320,"dataGaName":321,"dataGaLocation":457},{"text":323,"config":592},{"href":325,"dataGaName":326,"dataGaLocation":457},{"text":594,"config":595},"Sustainability",{"href":596,"dataGaName":594,"dataGaLocation":457},"/sustainability/",{"text":598,"config":599},"Vielfalt, Inklusion und Zugehörigkeit",{"href":600,"dataGaName":601,"dataGaLocation":457},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":328,"config":603},{"href":330,"dataGaName":331,"dataGaLocation":457},{"text":338,"config":605},{"href":340,"dataGaName":341,"dataGaLocation":457},{"text":343,"config":607},{"href":345,"dataGaName":346,"dataGaLocation":457},{"text":609,"config":610},"Transparenzerklärung zu moderner Sklaverei",{"href":611,"dataGaName":612,"dataGaLocation":457},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":614,"links":615},"Nimm Kontakt auf",[616,619,624,626,631,636,641],{"text":617,"config":618},"Sprich mit einem Experten/einer Expertin",{"href":50,"dataGaName":51,"dataGaLocation":457},{"text":620,"config":621},"Support",{"href":622,"dataGaName":623,"dataGaLocation":457},"/support/","get help",{"text":362,"config":625},{"href":364,"dataGaName":365,"dataGaLocation":457},{"text":627,"config":628},"Status",{"href":629,"dataGaName":630,"dataGaLocation":457},"https://status.gitlab.com/","status",{"text":632,"config":633},"Nutzungsbedingungen",{"href":634,"dataGaName":635,"dataGaLocation":457},"/terms/","terms of use",{"text":637,"config":638},"Datenschutzerklärung",{"href":639,"dataGaName":640,"dataGaLocation":457},"/de-de/privacy/","privacy statement",{"text":642,"config":643},"Cookie-Einstellungen",{"dataGaName":644,"dataGaLocation":457,"id":645,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":457},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":457},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":457,"id":645,"isOneTrustButton":27},[655],{"id":656,"title":18,"body":8,"config":657,"content":659,"description":8,"extension":25,"meta":663,"navigation":27,"path":664,"seo":665,"stem":666,"__hash__":667},"blogAuthors/en-us/blog/authors/michael-friedrich.yml",{"template":658},"BlogAuthor",{"name":18,"config":660},{"headshot":661,"ctfId":662},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659879/Blog/Author%20Headshots/dnsmichi-headshot.jpg","dnsmichi",{},"/en-us/blog/authors/michael-friedrich",{},"en-us/blog/authors/michael-friedrich","lJ-nfRIhdG49Arfrxdn1Vv4UppwD51BB13S3HwIswt4",[669,684,698],{"content":670,"config":682},{"category":9,"tags":671,"body":674,"date":675,"heroImage":676,"authors":677,"title":680,"description":681},[672,673,104],"tutorial","git","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/ee/user/permissions.html) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[678,679],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":27,"template":13,"slug":683},"migration-from-azure-devops-to-gitlab",{"content":685,"config":696},{"heroImage":686,"title":687,"description":688,"authors":689,"date":691,"category":9,"tags":692,"body":695},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","Wie wir die größte GitLab-Instanz 12-mal täglich bereitstellen","Systematische Deployment-Pipeline mit mehrstufigen Rollouts, Canary-Strategie (5% Traffic) und Datenbank-Migrationen für Millionen Entwickler(innen) weltweit.",[690],"John Skarbek","2025-12-01",[693,694],"product","inside GitLab","GitLab führt täglich bis zu 12 Code-Bereitstellungen auf der weltweit größten GitLab-Instanz – GitLab.com – ohne Ausfallzeiten durch. Diese Bereitstellungen nutzen GitLabs eigene CI/CD-Plattform und betreffen Millionen Entwickler(innen) weltweit. Die hohe Bereitstellungsfrequenz dient als primäres Qualitätstor und Belastungstest. Organisationen, die auf GitLab für ihre DevOps-Workflows setzen, nutzen eine auf der eigenen Infrastruktur im Enterprise-Maßstab bewährte Plattform.\n\nIn regulierten Branchen wie dem Finanzwesen und der Automobilproduktion sind Zero-Downtime-Bereitstellungen keine Option, sondern Voraussetzung. Die NIS2-Richtlinie fordert in Artikel 21 systematische Risikoanalyse und Business-Continuity-Management – genau das, was GitLab.coms progressive Rollout-Strategie in der Praxis demonstriert. Durch mehrstufige Validierung mit isoliertem Canary-Traffic (5% aller Anfragen) werden potenzielle Probleme erkannt, bevor Millionen Nutzer(innen) betroffen sind.\n\n## Die Herausforderung: Frequenz trifft Skalierung\n\n**Für GitLab:** Bereitstellungsfrequenz ist geschäftskritisch. Schnelle Deployment-Zyklen ermöglichen Reaktion auf Kundenfeedback innerhalb von Stunden, sofortige Security-Patches und Validierung neuer Features in Production vor Skalierung.\n\n**Für Kund(inn)en:** Jede Bereitstellung auf GitLab.com validiert die Deployment-Praktiken, die GitLab seinen Nutzer(inne)n empfiehlt. Features werden auf der weltweit größten GitLab-Instanz getestet, bevor sie Kundenumgebungen erreichen. Dies liefert:\n\n* Neueste Features sofort verfügbar (Stunden statt Wochen)\n* Bewährte Zuverlässigkeit im Maßstab\n* Zero-Downtime-Bereitstellungen garantieren durchgängigen Zugriff\n* Dokumentation basiert auf tatsächlichen Production-Praktiken\n\n## Code-to-Production-Architektur\n\nDie Deployment-Pipeline durchläuft strukturierte Phasen, wobei jede Phase als Checkpoint auf dem Weg zur Production-Bereitstellung fungiert:\n\n```mermaid\n    graph TD\n        A[Code Proposed] --> B[Merge Request Created]\n        B --> C[Pipeline Triggered]\n        C --> D[Build & Test]\n        D --> E{Spec/Integration/QA Tests Pass?}\n        E -->|No| F[Feedback Loop]\n        F --> B\n        E -->|Yes| G[Merge to default branch]\n        G -->|Periodically| H[Auto-Deploy Branch]\n\n        subgraph \"Deployment Pipeline\"\n            H --> I[Package Creation]\n            I --> K[Canary Environment]\n            K --> L[QA Validation]\n            L --> M[Main Environment]\n\n        end\n```\n\n## Progressive Rollout-Strategie\n\n### Build und Paket-Erstellung\n\nGitLab erstellt sowohl Omnibus-Pakete als auch Cloud Native GitLab (CNG) Images. Omnibus-Pakete werden auf der Gitaly-Flotte bereitgestellt (Git-Storage-Layer), während CNG-Images alle anderen Komponenten als containerisierte Workloads ausführen. Eine geplante Pipeline sucht regelmäßig nach dem jüngsten Commit mit erfolgreicher Pipeline und erstellt daraus einen Auto-Deploy-Branch.\n\n```mermaid\n    graph LR\n        A[Create branch] --> B[Build]\n        B --> C[Choose Built package]\n        C --> D[Start Deploy Pipeline]\n```\n\n### Canary-Strategie und mehrstufige Validierung\n\nGitLabs QA-Prozess arbeitet Hand in Hand mit der Canary-Strategie durch umgebungsbasierte Validierung. [Etwa 5% des gesamten Traffics durchlaufen die Canary-Stage](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Dieser Ansatz erhöht die Komplexität von Datenbankmigrationen, gewährleistet aber nahtlose Bereitstellung eines zuverlässigen Produkts.\n\n**Progressive Rollout-Phasen:**\n\n1. **Staging Canary:** Initiale Validierungsumgebung\n2. **Production Canary:** Limitierter Production-Traffic\n3. **Staging Main:** Vollständige Staging-Umgebung\n4. **Production Main:** Vollständiger Production-Rollout\n\n```mermaid\n    graph TD\n        C[Staging Canary Deploy]\n        C --> D[QA Smoke Main Stage Tests]\n        C --> E[QA Smoke Canary Stage Tests]\n        D --> F\n        E --> F{Tests Pass?}\n        F -->|Yes| G[Production Canary Deploy]\n        G --> S[QA Smoke Main Stage Tests]\n        G --> T[QA Smoke Canary Stage Tests]\n        F -->|No| H[Issue Creation]\n        H --> K[Fix & Backport]\n        K --> C\n\n        S --> M[Canary Traffic Monitoring]\n        T --> M[Canary Traffic Monitoring baking period]\n        M --> U[Production Safety Checks]\n        U --> N[Staging Main]\n        N --> V[Production Main]\n```\n\nQA-Validierung erfolgt an mehreren Checkpoints: nach jeder Canary-Bereitstellung und nach Post-Deploy-Migrationen. Weitere Details zur [GitLab-Teststrategie](https://handbook.gitlab.com/handbook/engineering/testing/) finden sich im Handbook.\n\n## Deployment-Pipeline-Stages\n\nGitLab.com repräsentiert reale Deployment-Komplexität im Maßstab. Als größte bekannte GitLab-Instanz nutzen Bereitstellungen denselben offiziellen GitLab Helm Chart und dasselbe Linux-Paket wie Kund(inn)en. Mehr zur [GitLab.com-Architektur](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) im Handbook.\n\n**Dogfooding im Maßstab:** GitLab nutzt dieselben Verfahren, die für [Zero-Downtime-Upgrades](https://docs.gitlab.com/update/zero_downtime/) dokumentiert sind. Was bei GitLab nicht reibungslos funktioniert, wird Kund(inn)en nicht empfohlen.\n\nFolgende Stages laufen für alle Environment- und Stage-Upgrades:\n\n```mermaid\n    graph LR\n        a[prep] --> c[Regular Migrations - Canary stage only]\n        a --> f[Assets - Canary stage only]\n        c --> d[Gitaly]\n        d --> k8s\n\n        subgraph subGraph0[\"VM workloads\"]\n          d[\"Gitaly\"]\n        end\n\n        subgraph subGraph1[\"Kubernetes workloads\"]\n          k8s[\"k8s\"]\n        end\n\n        subgraph fleet[\"fleet\"]\n          subGraph0\n          subGraph1\n        end\n```\n\n**Stage-Details:**\n\n* **Prep:** Validiert Deployment-Bereitschaft und führt Pre-Deployment-Checks durch\n* **Migrations:** Führt reguläre Datenbankmigrationen aus (nur Canary-Stage)\n* **Assets:** Lädt statische Assets in GCS-Bucket hoch (nur Canary-Stage)\n* **Gitaly:** Aktualisiert Gitaly-VM-Storage-Layer via Omnibus-Paket\n* **Kubernetes:** Deployed containerisierte GitLab-Komponenten via Helm Chart\n\n### Multi-Version-Kompatibilität: Die versteckte Herausforderung\n\nWährend der Bereitstellung existiert eine Zeitspanne, in der das Datenbankschema dem Code voraus ist, den die Main-Stage kennt. Dies geschieht, weil die Canary-Stage bereits neuen Code deployed und reguläre Datenbankmigrationen ausführt, während die Main-Stage noch die vorherige Code-Version ausführt.\n\n**Beispiel:** Bei Hinzufügen eines neuen `merge_readiness`-Felds zu Merge Requests laufen manche Server mit Code, der dieses Feld erwartet, während andere nichts davon wissen. Schlechte Handhabung würde GitLab.com für Millionen Nutzer(innen) unterbrechen. Gute Handhabung bleibt unbemerkt.\n\nMit wenigen Ausnahmen läuft die Mehrheit der Services für eine gewisse Zeit in leicht neuerer Version in Canary. Diese Szenarien sind transiente Zustände, können aber mehrere Stunden oder Tage in Live-Production-Umgebung persistieren. Daher müssen sie mit derselben Sorgfalt wie permanente Zustände behandelt werden.\n\n## Datenbank-Operationen\n\nDatenbankmigrationen stellen eine besondere Herausforderung im Canary-Deployment-Modell dar. Schemaänderungen müssen neue Features unterstützen und gleichzeitig Rollback-Fähigkeit bewahren:\n\n* **Regular Migrations:** Laufen während Canary-Stage, rückwärtskompatibel, nur reversible Änderungen\n* **Post-Deploy-Migrations:** \"Point of no Return\"-Migrationen, die erst nach mehreren erfolgreichen Bereitstellungen laufen\n\n```mermaid\n    graph LR\n        A[Regular Migrations] --> B[Canary Stage Deploy]\n        B --> C[Main Stage Deploy]\n        C --> D[Post Deploy Migrations]\n```\n\nPost-Deploy-Migrationen enthalten oft Änderungen, die nicht einfach rückgängig gemacht werden können – Datentransformationen, Column-Drops oder strukturelle Änderungen, die ältere Code-Versionen unterbrechen würden. Durch Ausführung nach Erlangung von Vertrauen durch mehrere erfolgreiche Bereitstellungen wird sichergestellt:\n\n1. Neuer Code ist stabil, Rollback unwahrscheinlich\n2. Performance-Charakteristiken in Production verstanden\n3. Edge Cases erkannt und adressiert\n4. Blast Radius minimiert, falls etwas schiefgeht\n\nDieser Ansatz bietet optimale Balance: schnelle Feature-Bereitstellung durch Canary-Releases bei gleichzeitiger Rollback-Fähigkeit bis Vertrauen in Deployment-Stabilität besteht.\n\n**Expand-Migrate-Contract-Pattern:** Datenbank-, Frontend- und Anwendungskompatibilitäts-Änderungen folgen einem sorgfältig orchestrierten dreiphasigen Ansatz:\n\n1. **Expand:** Neue Strukturen hinzufügen, alte funktional belassen\n2. **Migrate:** Neuen Application-Code deployen, der neue Strukturen nutzt\n3. **Contract:** Alte Strukturen in Post-Deploy-Migrationen entfernen\n\n**Beispiel für `merge_readiness`-Column:**\n\n1. **Expand:** Neue Column mit Default-Value hinzufügen; bestehender Code ignoriert sie\n2. **Migrate:** Code deployen, der neue Column liest und schreibt, alten Ansatz weiter unterstützt\n3. **Contract:** Nach mehreren erfolgreichen Bereitstellungen alte Column in Post-Deploy-Migration entfernen\n\nAlle Datenbank-Operationen, Application-Code und Frontend-Code unterliegen Guidelines, dokumentiert in der [Multi-Version-Compatibility-Dokumentation](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n## Ergebnisse und Auswirkungen\n\n**Für GitLab:**\n\n* Bis zu 12 Bereitstellungen täglich auf GitLab.com\n* Zero-Downtime-Bereitstellungen für Millionen Entwickler(innen)\n* Security-Patches erreichen Production innerhalb von Stunden\n* Neue Features in Production im Maßstab validiert vor General Availability\n\n**Für Kunden:**\n\n* Bewährte Deployment-Patterns für eigene Anwendungen\n* Features auf weltweit größter GitLab-Instanz getestet vor Erreichen der Kundenumgebung\n* Dokumentation reflektiert tatsächliche Production-Praktiken\n* Vertrauen, dass GitLabs empfohlene Upgrade-Prozeduren in jedem Maßstab funktionieren\n\n## Erkenntnisse für Engineering-Teams\n\nDie hier beschriebenen Muster – von Expand-Migrate-Contract für Datenbankmigrationen bis zur Multi-Version-Kompatibilität – sind auf kleinere Deployments übertragbar. Nicht jede Organisation benötigt 12 Bereitstellungen täglich, aber die systematische Herangehensweise an Rollback-Fähigkeit und Validierungspunkte gilt unabhängig von der Skalierung.\n\nGitLabs Deployment-Pipeline repräsentiert ein ausgereiftes System, das Deployment-Geschwindigkeit mit operationaler Zuverlässigkeit ausbalanciert. Das progressive Deployment-Modell, umfassende Testing-Integration und robuste Rollback-Fähigkeiten bieten Grundlage für zuverlässige Software-Auslieferung im Maßstab.\n\n**Zentrale Überlegungen für Engineering-Teams:**\n\n* **Automatisiertes Testing:** Umfassende Test-Coverage durch Deployment-Pipeline\n* **Progressive Rollouts:** Gestufte Bereitstellungen zur Risikominimierung und schnellen Wiederherstellung\n* **Monitoring-Integration:** Umfassende Observability über alle Deployment-Stages\n* **Incident Response:** Schnelle Erkennungs- und Lösungsfähigkeiten für Deployment-Probleme\n\nGitLabs Architektur demonstriert, wie moderne CI/CD-Systeme Komplexität großskaliger Bereitstellungen managen und gleichzeitig Geschwindigkeit für wettbewerbsfähige Software-Entwicklung bewahren.\n\n## Vollständige technische Dokumentation\n\nDieser Artikel beschreibt die Deployment-Patterns und systematische Herangehensweise für GitLab.com. Für vollständige Implementierungsdetails, spezifische Konfigurationsbeispiele und tiefergehende technische Architekturbeschreibungen siehe die [englische Originalversion](https://about.gitlab.com/blog/continuously-deploying-the-largest-gitlab-instance/).\n\nWeitere Dokumentation zu Auto-Deploy und Verfahren:\n\n* [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n* [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n* [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)\n\n## Weitere Ressourcen\n\n* [How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n* [How we supercharged GitLab CI statuses with WebSockets](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n* [How we reduced MR review time with Value Stream Management](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)",{"featured":27,"template":13,"slug":697},"continuously-deploying-the-largest-gitlab-instance",{"content":699,"config":712},{"title":700,"description":701,"authors":702,"heroImage":704,"date":705,"category":9,"tags":706,"body":711},"MR-Review-Zeit mit Value Stream Management reduzieren","GitLab Engineering nutzt VSM zur Identifikation von Engpässen im MR-Review-Prozess. Systematische Analyse mit Custom Stages.",[703],"Haim Snir","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097876/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097875817.png","2025-10-30",[693,707,708,709,710],"features","DevSecOps platform","workflow","solutions architecture","Das GitLab Engineering-Team nutzt die eigenen Produkte intern – eine Praxis, die im Englischen als \"Dogfooding\" bezeichnet wird. Diese Selbstnutzung hat zu Verbesserungen bei der Beschleunigung der Software-Delivery-Zyklen für Kunden geführt. Dieser Artikel beleuchtet einen spezifischen Anwendungsfall, bei dem [GitLab Value Stream Management (VSM)](https://about.gitlab.com/solutions/value-stream-management/) Verbesserungen für unser Engineering-Team ermöglicht hat. Es wird gezeigt, wie VSM dabei half, zwei zentrale Herausforderungen anzugehen: die Messung des Wegs von der Idee bis zur Fertigstellung eines Merge Requests und die Optimierung der Deployment-Workflows.\n\nValue Stream Management ist in der deutschen Industrie als Wertstromanalyse etabliert – insbesondere in der Fertigung und Automobilbranche wird diese Lean-Methode zur Identifikation von Verschwendung eingesetzt. GitLabs VSM-Funktionen übertragen diesen systematischen Ansatz auf Software-Entwicklungsprozesse und ermöglichen die Unterscheidung zwischen wertschöpfenden und nicht-wertschöpfenden Aktivitäten im Entwicklungsworkflow.\n\n## Die Herausforderung: Engpässe in MR-Reviews identifizieren\n\nTrotz gut definierter Workflows stellte ein Team fest, dass Merge Requests länger als erwartet brauchten, um geprüft und gemerged zu werden. Die Herausforderung bestand nicht nur in den Verzögerungen selbst, sondern darin zu verstehen, wo im Review-Prozess diese Verzögerungen auftraten und warum.\n\nDas Ziel des Teams war klar:\n\n- Identifizieren, wo Zeit vom initialen Konzept bis zum finalen Merge eines MR verbracht wurde\n- Spezifische Engpässe im Review-Prozess lokalisieren\n- Verstehen, wie MR-Größe, Komplexität oder Dokumentationsqualität die Review-Zeit beeinflussen\n\n## Der Ansatz: MR-Review-Zeit in GitLab Value Stream Analytics messen\n\nValue Stream Analytics (VSA) ermöglicht es Organisationen, ihren gesamten Workflow von der Idee bis zur Auslieferung abzubilden und dabei zwischen wertschöpfenden Aktivitäten (VA) und nicht-wertschöpfenden Aktivitäten (NVA) im Prozessfluss zu unterscheiden. Durch die Berechnung des Verhältnisses von wertschöpfender Zeit zur gesamten Lead Time kann das Team verschwenderische Aktivitäten identifizieren, die zu Verzögerungen bei MR-Reviews führen.\n\nUm die notwendigen Metriken zu erhalten, passte das Team GitLab VSA an, um bessere Sichtbarkeit in den MR-Review-Prozess zu erhalten.\n\n### 1. Custom Stage für MR-Review einrichten\n\nDas Team fügte eine [neue Custom Stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) in VSA mit dem Namen **Review Time to Merge** hinzu, um spezifisch die Zeit vom ersten Zuweisen eines Reviewers bis zum Merge des MR zu tracken.\n\n- Start-Event: MR first reviewer assigned\n- End-Event: MR merged\n\nDurch die Definition dieser Stage begann VSA, die Dauer des MR-Review-Prozesses zu messen und lieferte präzise Daten darüber, wo Zeit verbracht wurde.\n\n![Defining stage of VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097883929.png)\n\n### 2. Total Time Chart für Klarheit nutzen\n\nMit der Custom Stage eingerichtet, nutzte das Team das [**Total Time Chart** auf der VSA Overview-Seite](https://about.gitlab.com/blog/value-stream-total-time-chart/) (**Analyze > Value Stream**), um zu visualisieren, wie viel Zeit während der neuen MR-Review-Stage verbracht wurde. Durch den Vergleich der Werte, die durch jeden Bereich im Chart dargestellt wurden, konnte das Team schnell identifizieren, wie diese Stage zur gesamten Software-Delivery-Lifecycle-Zeit (SDLC) beitrug.\n\n![total time chart for VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097883930.png)\n\n### 3. Für tiefere Erkenntnisse detailliert analysieren\n\nUm spezifische Verzögerungen zu untersuchen, nutzte das Team die **Stage Navigation Bar**, um tiefer in die MR-Review-Stage einzutauchen. Diese Ansicht ermöglichte:\n\n- MRs nach Review-Zeit sortieren: Die Stage-Tabelle zeigte alle zugehörigen MRs sortiert nach Review-Dauer, sodass langsame MRs leicht erkennbar waren\n- Individuelle MRs analysieren: Für jeden MR konnte das Team Faktoren wie Verzögerungen bei der Reviewer-Zuweisung, mehrere Feedback-Runden, Leerlaufzeit nach Approval und MR-Größe/Komplexität untersuchen\n\n## Das Ergebnis: Umsetzbare Erkenntnisse und Verbesserungen\n\nDurch die Anpassung von VSA zur Verfolgung der [MR-Review-Zeit](https://docs.gitlab.com/user/project/merge_requests/reviews/) deckte das Team mehrere zentrale Erkenntnisse auf:\n\n- **Verzögerungen bei Reviewer-Zuweisung:** Einige MRs erfuhren Verzögerungen, weil Reviewer spät zugewiesen wurden oder Reviewer zu viele MRs in ihrer Queue hatten\n- **Langsame Review-Start-Zeiten:** Selbst nach Zuweisung lagen bestimmte MRs untätig, bevor Reviews begannen – oft aufgrund von Kontextwechseln oder konkurrierenden Prioritäten\n- **Mehrere Feedback-Schleifen:** Größere MRs erforderten oft mehrere Feedback-Runden, was die Review-Zeit erheblich verlängerte\n- **Leerlaufzeit nach Approval:** Einige MRs wurden approved, aber nicht zeitnah gemerged – oft aufgrund von Deployment-Koordinationsproblemen\n\nFür den Engineering Manager im Team erwies sich VSA als wertvoll für die Verwaltung des Team-Workflows: \"Ich habe VSA genutzt, um zu begründen, wo wir Zeit bei der MR-Fertigstellung verbrachten. Wir haben VSA auf unsere Bedürfnisse angepasst, und es war sehr hilfreich für unsere Untersuchungen nach Verbesserungsmöglichkeiten.\"\n\nAus dieser Dogfooding-Erfahrung entwickeln wir nun eine wichtige Erweiterung zur Verbesserung der Sichtbarkeit in den Review-Prozess. Wir fügen ein neues Event zu VSA hinzu – [Merge request last approved at](https://gitlab.com/gitlab-org/gitlab/-/issues/503754) – das eine Stage erzeugt, die MR-Review-Schritte noch granularer aufschlüsselt.\n\n## Die Kraft datengestützter Entscheidungen\n\nDurch die Nutzung von GitLabs VSA haben wir nicht nur Engpässe identifiziert – wir erhielten umsetzbare Erkenntnisse, die zu Verbesserungen bei der MR-Review-Zeit und der allgemeinen Entwickler-Produktivität führten. Wir optimierten Merge-Request-Review-Zyklen und erhöhten den Entwickler-Durchsatz, was unser Commitment zu kontinuierlicher Verbesserung durch Messung bestätigt.\n\n> Möchtest du erfahren, wie VSA deinem Team helfen kann? [Starte eine kostenlose GitLab Ultimate-Testversion](https://about.gitlab.com/free-trial/), passe deine Value Streams an und sieh, wie du Verbesserungen im gesamten SDLC für deine Teams erreichen kannst. [Teile dann dein Feedback und deine Erfahrungen in diesem Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/520962).\n\n## Weiterführende Informationen\n\n- [Optimize value stream efficiency to do more with less, faster](https://about.gitlab.com/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/)\n- [New Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Value stream analytics documentation](https://docs.gitlab.com/user/group/value_stream_analytics/)\n- [Value stream management: Total Time Chart simplifies top-down optimization flow](https://about.gitlab.com/blog/value-stream-total-time-chart/)\n",{"slug":713,"featured":12,"template":13},"how-we-reduced-mr-review-time-with-value-stream-management",{"promotions":715},[716,730,741],{"id":717,"categories":718,"header":720,"text":721,"button":722,"image":727},"ai-modernization",[719],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":723,"config":724},"Get your AI maturity score",{"href":725,"dataGaName":726,"dataGaLocation":240},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":728},{"src":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":731,"categories":732,"header":733,"text":721,"button":734,"image":738},"devops-modernization",[693,32],"Are you just managing tools or shipping innovation?",{"text":735,"config":736},"Get your DevOps maturity score",{"href":737,"dataGaName":726,"dataGaLocation":240},"/assessments/devops-modernization-assessment/",{"config":739},{"src":740},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":742,"categories":743,"header":745,"text":721,"button":746,"image":750},"security-modernization",[744],"security","Are you trading speed for security?",{"text":747,"config":748},"Get your security maturity score",{"href":749,"dataGaName":726,"dataGaLocation":240},"/assessments/security-modernization-assessment/",{"config":751},{"src":752},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":754,"blurb":755,"button":756,"secondaryButton":761},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":757,"config":758},"Kostenlosen Test starten",{"href":759,"dataGaName":46,"dataGaLocation":760},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":48,"config":762},{"href":50,"dataGaName":51,"dataGaLocation":760},1772652053210]