[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"/de-de/blog/gitlab-flow-duo":3,"navigation-de-de":43,"banner-de-de":456,"footer-de-de":466,"blog-post-authors-de-de-Cesar Saavedra":699,"blog-related-posts-de-de-gitlab-flow-duo":713,"blog-promotions-de-de":751,"next-steps-de-de":803},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":26,"externalUrl":27,"featured":14,"heroImage":19,"isFeatured":14,"meta":28,"navigation":29,"path":30,"publishedDate":20,"rawbody":31,"seo":32,"slug":13,"stem":36,"tagSlugs":37,"tags":41,"template":15,"updatedDate":25,"__hash__":42},"blogPosts/de-de/blog/gitlab-flow-duo.yml","Kombiniere GitLab Flow und GitLab Duo für starke Workflows",[7],"cesar-saavedra",[9],"Cesar Saavedra","Für den Einstieg in DevSecOps ist ein gut durchdachter Workflow nötig – doch das kann oft eine echte Herausforderung sein. Zum Glück gibt es zwei Dinge, die dir dabei helfen können:\n**GitLab Flow und GitLab Duo.**\n\nGitLab Flow ist ein vorgefertigter Ansatz, der Unternehmen dabei hilft, DevSecOps-Prozesse erfolgreich umzusetzen. GitLab Duo ist ein [leistungsstarkes Set an KI-basierten Funktionen](https://about.gitlab.com/blog/supercharge-productivity-with-gitlab-duo/) in der DevSecOps-Plattform von GitLab, das Unternehmen dabei helfen kann, Code zu entwickeln, den Betrieb zu optimieren und Software effizienter zu schützen. Zusammen helfen GitLab Flow und GitLab Duo Unternehmen dabei, die Effizienz ihrer Workflows durchgängig deutlich zu verbessern. Das führt dann zu noch höherer Produktivität, Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie zu Resilienz und Verfügbarkeit der Produktion.\n\nIn diesem Artikel erfährst du, wie GitLab Flow und GitLab Duo zusammen dazu beitragen können, Unternehmen mit DevSecOps zum Erfolg zu führen.\n\n > Entdecke die Zukunft von KI-gestützter Softwareentwicklung mit unserem virtuellen Launch-Event zu GitLab 17.  [Jetzt ansehen!](https://about.gitlab.com/de-de/eighteen/)\n\n## Was ist GitLab Flow?\nGitLab Flow ist ein vorgefertigter, festgelegter und durchgängiger Workflow für den Entwicklungslebenszyklus von Anwendungen mit GitLab, einer KI-basierten DevSecOps-Plattform, die eine einheitliche Benutzeroberfläche und ein einheitliches Datenmodell bietet. GitLab Flow baut auf bewährten Methoden und Erfahrungen aus Kundenfeedback und unserem Dogfooding auf. Außerdem deckt GitLab Flow alle [Phasen des DevSecOps-Lebenszyklus](https://about.gitlab.com/de-de/stages-devops-lifecycle/) ab und ermöglicht so einen effizienten Workflow, der aus einer inneren Feedbackschleife für Reviews bestimmter Updates sowie einer äußeren Feedbackschleife für die Verbesserung der gesamten Anwendung sowie des Entwicklungsprozesses an sich besteht.\n\n![Innere und äußere Feedbackschleifen von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-feedback-loops.png)\n\u003Ccenter>Innere und äußere Feedbackschleifen von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nWie du an den vielen Phasen in GitLab Flow erkennen kannst, besteht die Entwicklung einer Software aus viel mehr als dem reinen Programmieren. Im Folgenden erfährst du mehr über jeden Schritt von GitLab Flow und darüber, wie GitLab Duo dich dabei unterstützen kann.\n\n### Planen\nDas erste Element von GitLab Flow ist die Planung, die sich in der äußeren Feedbackschleife von GitLab Flow befindet. Sie umfasst Tickets, Merge Requests, Epics, Meilensteine, Iterationen, Veröffentlichungen, Release-Nachweise und mehr. Im Folgenden erfährst du, welche Rolle diese Komponenten in GitLab Flow spielen und wie dich GitLab Duo dabei unterstützen kann.\n\n![Planen – das erste Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-planning-portion.png)\n\u003Ccenter>Planen – das erste Element in GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n#### Tickets\nTickets sind die Elemente, in denen Produktprobleme oder neue Funktionen definiert werden und in denen Teammitglieder zusammenarbeiten können. Wenn ein Ticket erstellt wird, kannst du seinen Titel ausfüllen und dann die Funktion GitLab Duo **Issue Description Generation** nutzen, um die Beschreibung zu erstellen. So sparst du Zeit und hast weniger Aufwand. Da viele Beteiligte an Kommentar-Threads in einem Ticket mitarbeiten können, ist die **Diskussionszusammenfassung** eine KI-basierte Funktion von GitLab Duo, die dir hunderte Kommentare zu einem Ticket in einem kurzen Absatz zusammenfasst. So erhalten die Beteiligten rasch einen Überblick über die Konversation, können sich direkt an der Diskussion beteiligen und sofort produktiv werden.\n\nTickets können in Issue-Übersichten organisiert und visualisiert werden. Dabei handelt es sich um ein Software-Projektmanagementtool, das als Kanban- oder Scrum-Board eingesetzt werden kann. Mit diesen Boards können Teams den Workflow einer Funktion oder einer Produkt-Release einfacher planen, organisieren und visualisieren. Es können verschiedene Kategorien von Boards erstellt werden, wobei Tickets ganz einfach per Drag & Drop von einem zum anderen gezogen werden können.\n\n#### Merge Requests\nMerge Requests sind die Elemente, in denen Lösungen entwickelt werden. Tickets und Merge Requests sind Bestandteile einer Release und ermöglichen, dass Änderungen an Anwendungen, die von Beteiligten wie DevOps und Platform Engineers, System- und Datenbankadministrator(innen), Security Engineers und Entwickler(inne)n vorgenommen werden, überprüft und nachverfolgt werden können. Darüber hinaus sind Tickets und Merge Requests wichtige Inputs für den Release-Planungsprozess.\n\nMerge Requests können einzeln oder aus einem Ticket erstellt werden. Wenn du ein Merge Request aus einem Ticket erstellst, wird es automatisch dem Ticket zugeordnet. Wenn der Merge Request dann zusammengeführt wird, wird das zugehörige Ticket automatisch geschlossen. Merge Requests können auch manuell mit einem Ticket verknüpft werden.\n\n![Der Merge Request schließt das Ticket](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/mr-with-its-issue.png)\n\u003Ccenter>Der Merge Request schließt das Ticket\u003C/center>\u003Cp>\u003C/p>\n\nÄhnlich wie Tickets können auch Merge Requests eine lange Liste an Updates an einem Feature-Branch, die durch verschiedene Beteiligte vorgenommen wurden, enthalten. Mitwirkende, die sich mit den Updates vertraut machen möchten oder alle Updates in einem Merge Request verstehen müssen, können die Funktion **Merge-Request-Zusammenfassung** in GitLab Duo nutzen, um einen raschen Überblick über die Änderungen zu erhalten. Darüber hinaus können die Mitwirkenden mit der Funktion GitLab Duo **Code Merge Request Template Population** eine vorab erstellte Merge-Request-Vorlage heranziehen, die automatisch mit den entsprechenden Inhalten ausgefüllt wird. Beschreibungsvorlagen sind eine Möglichkeit, die Zusammenarbeit und Kommunikation im gesamten Entwicklungslebenszyklus zu standardisieren und zu optimieren – und mit GitLab Duo geht das noch schneller!\n\nTickets mit demselben Thema können in einem Epic gruppiert werden, um die zu erledigenden Arbeiten zu organisieren. Epics können untergeordnete Tickets und Sub-Epics haben und/oder mit anderen Epics im gesamten Unternehmen verknüpft werden. Mit Iterationen können Sprints nachverfolgt werden, und sie können manuell oder mithilfe von Iterationskadenzen automatisch geplant werden, um die Planungs-Workflows zu optimieren. Außerdem umfassen Iterationen Abarbeitungs- und Burnup-Diagramme. Abarbeitungsdiagramme helfen dabei, den Gesamtfortschritt im Projektumfang nachzuverfolgen, während Burnup-Diagramme die tägliche Anzahl und Gewichtung von Tickets messen, die in einer bestimmten Timebox hinzugefügt und abgeschlossen wurden.\n\n#### Meilensteine\nMithilfe von Meilensteinen können Teams ihre Tickets und Merge Requests in einer zusammenhängenden Gruppe mit optionalem Start- und Fälligkeitsdatum organisieren. Meilensteine werden in der Regel verwendet, um Releases nachzuverfolgen. Außerdem kann man mit ihnen Tickets und Merge Requests auf Projekt- oder Gruppenebene nachverfolgen. Ähnlich wie Iterationen gibt es auch bei Meilensteinen Abarbeitungs- und Burnup-Diagramme, die den Fortschritt zeigen.\n\nMeilensteine können mit einer Release verknüpft werden, bei deren Erstellung automatisch Artefakte wie etwa ein Release-Nachweis erstellt werden. Der Release-Nachweis ist eine automatisch gesammelte Momentaufnahme der Daten, die mit dieser Release zusammenhängen. Neben Testartefakten und verknüpften Meilensteinen kann der Release-Nachweis auch Jobartefakte enthalten, die sich auf interne Prozesse wie externe Audits beziehen.\n\nEpics, Meilensteine und Iterationen können über Roadmaps visualisiert werden, die dir dabei helfen, den Release-Fortschritt nachzuverfolgen und den Release-Prozess zu optimieren.\n\nSobald die Planung erfolgt ist, können die Arbeiten beginnen, die für die Lösung eines Problems oder die Entwicklung einer neuen Funktion erforderlich sind. Dies geschieht in Merge Requests. Im Folgenden erfährst du, wie das in GitLab Flow funktioniert.\n> [Erfahre mehr, indem du GitLab Flow und GitLab Duo ausprobierst](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F).\n\n### Merge Requests und Pushen von Code\n\n![Merge Requests und Pushen von Code – das zweite Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-mr-pushing-code-portion.png)\n\u003Ccenter>Merge Requests und Pushen von Code – das zweite Element in GitLab Flow \u003C/center>\u003Cp>\u003C/p>\n\nDas zweite Element von GitLab Flow betrifft Merge Requests und das Pushen von Code. Wie bereits erwähnt sind Merge Requests jene Orte, an denen die Beteiligten in einem Unternehmens an Lösungen zusammenarbeiten. Diese Zusammenarbeit kann verteilt und asynchron erfolgen. Die Mitwirkenden können die Kooperationsfunktionen wie Tagging, Inline-Vorschläge, Inline-Kommentare, Merge-Request-Kommentare, Review Threads und Review Requests nutzen, um gemeinsam die Codequalität, Verfügbarkeit, Zuverlässigkeit und Leistung zu verbessern. Direkt nach der Erstellung eines Merge Requests beginnt die innere Feedbackschleife von GitLab Flow, in der Code, Fix-Pushes, Tests und Scans durchgeführt werden. Hier finden außerdem Reviews zur Zusammenarbeit und zu Updates statt.\n\n#### Pipelines\nWenn Updates über Merge Requests auf einen Feature-Branch angewendet werden, werden automatisch Pipelines ausgeführt, falls diese vorab festgelegt wurden. Pipelines können mehrere Phasen und Jobs haben, um die Anwendung oder den Microservice in einer Review-Umgebung zu erstellen, zu testen und dann bereitzustellen. In dieser Review-Umgebung können Updates dynamisch verifiziert werden, bevor sie in den Haupt-Branch zusammengeführt werden. Diese Automatisierung trägt dazu bei, den Update- und Review-Prozess von Anwendungen zu optimieren.\n\nZudem stellen DevSecOps-Teams, die über Merge Requests Updates an Anwendungen vornehmen, eine Vielzahl an KI-basierten Funktionen zur Verfügung. Wenn sie Code schreiben oder aktualisieren, kann GitLab Duo **Codevorschläge** Code empfehlen, der an dieser Stelle passen würde, und die Entwickler(innen) können entscheiden, ob sie diese Empfehlung annehmen oder ignorieren möchten. Codevorschläge unterstützen dich bei der Codeerstellung über Prompts sowie durch die Code-Vervollständigung, die angezeigt wird, während du schreibst. Codevorschläge können das Programmiererlebnis verbessern, indem sie Fehler reduzieren und es den Entwickler(inne)n ermöglichen, schneller Code zu schreiben. Dies trägt wiederum dazu bei, die Qualität des Produktionscodes zu verbessern. Codevorschläge können außerdem zu einer höheren Produktivität der Entwickler(innen) und schnelleren Iterationen und Rollouts führen.\n\nDa verschiedene Stakeholder innerhalb der Organisation an der Entwicklung oder Überprüfung von Anwendungen beteiligt sind, können sie auf Code stoßen, der schlecht dokumentiert, komplex oder schwer zu verstehen ist oder in einer ihnen unbekannten Programmiersprache geschrieben ist. Die Funktion **Codeerläuterung** von GitLab Duo erklärt den Code in natürlicher Sprache, sodass jeder den Code verstehen und schnell auf dem neuesten Stand sein kann.\n\nWenn Aktualisierungen in den Feature-Branch committet werden, verwendet die GitLab-Duo-Funktion **Vorgeschlagene Prüfer(innen)** die Änderungen in einem Merge Request und das Mitarbeiterdiagramm eines Projekts, um geeignete Prüfer(innen) im Dropdown in der Seitenleiste des Merge Request vorzuschlagen. Die Liste enthält Benutzer(innen), die sich mit einem bestimmten Aspekt der Anwendung auskennen und daher am besten dazu geeignet sind, die Updates zu überprüfen. Entwickler(innen) sparen Zeit, da sie die am besten geeignet Prüfer(innen) nicht suchen und identifizieren müssen sowie den Überprüfungsprozess rationalisieren und Verzögerungen und Reviews von geringer Qualität vermeiden können.Wenn Entwickler(innen) Änderungen am Code vornehmen, fügen sie im Merge Request oft keine Kommentare zu den spezifischen Änderungen hinzu, die sie vorgenommen haben. Mit der **Merge-Request-Zusammenfassung** von GitLab Duo kann die bzw. der Autor(in) von Merge-Request-Änderungen mithilfe der KI einen Kommentar in natürlicher Sprache generieren, der die Updates am Code zusammenfasst. Prüfer(innen) können dann die Änderungen besser verstehen und den gesamten Überprüfungsprozess optimieren.\n\nWenn Prüfer(innen) Updates des Codes in einem Merge Request überprüfen, können sie den Merge Request blockieren. Die Begründung kann aus vielen Kommentaren bestehen, die sich über viele Quelldateien erstrecken. Um der bzw. dem ursprünglichen Autor(in) der Updates zu helfen, das Feedback der Prüferin oder des Prüfers in einem langen Block besser zu verstehen, erstellt die **Code-Review-Zusammenfassung** von GitLab Duo eine Zusammenfassung des Feedbacks der Prüferin bzw. des Prüfers in natürlicher Sprache. Dies ermöglicht eine bessere Übergabe zwischen Autor(inn)en und Prüfer(inne)n, wodurch der Review-Prozess optimiert wird.\n\nWenn Entwickler(innen) neuen Code über einen Merge Request hinzufügen, können sie außerdem die **Testgenerierung** von GitLab Duo nutzen, die mithilfe von KI Unit-Tests für den neuen Code generiert. Dies kann dazu beitragen, die Produktivität der Entwickler(innen) zu erhöhen, die Testabdeckung zu verbessern und Fehler frühzeitig im Entwicklungslebenszyklus zu erkennen. Entwickler(innen) können auch den jederzeit verfügbaren **Chat** von GitLab Duo nutzen, um Code zu refaktorisieren und Inline-Dokumentation wie z. B. Docstrings für ihren Quellcode erstellen.\n\nPipelines werden auf Branch-Updates ausgeführt und können automatisierte Tests und Scans enthalten, die dazu beitragen, die Sicherheit schon im Vorfeld zu kontrollieren.\n\n### Sicherheit im Vorfeld kontrollieren (Shift-Left-Ansatz)\n\n![Sicherheit im Vorfeld kontrollieren – das dritte Element von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-shift-sec-left-portion.png)\n\u003Ccenter>Sicherheit im Vorfeld kontrollieren – das dritte Element von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nDas dritte Element von GitLab Flow ist, dass die Sicherheit im Vorfeld kontrolliert wird. Diese Kontrolle ist auch Teil der inneren Feedbackschlaufe von GitLab Flow.\n\nNeben DevOps und Platform Engineers, System- und Datenbankadministrator(innen) und Entwickler(innen) betrifft die Sicherheit und Compliance auch einige der Beteiligten, die in einem Merge Request zusammenarbeiten, also an einem Ort, an dem automatisierte Tests und Sicherheitsscans eine Rolle spielen. Scans können einfach über praktisch nutzbare Vorlagen in eine Pipeline aufgenommen werden und/oder automatisch in einer Merge-Request-Pipeline ausgeführt werden. GitLab bietet eine Reihe an integrierten Sicherheitsscannern und Analysatoren, die von GitLab Flow genutzt werden können, doch auf der DevSecOps-Plattform sind auch Scanner von Drittanbietern sowie benutzerdefinierte Scanner möglich.\n\nGitLab Flow kontrolliert die Sicherheit im Vorfeld und verschiebt sie an den Anfang der Pipeline, um Fehler so früh wie möglich im Softwareentwicklungsprozess zu erkennen und zu beheben. Es ist viel einfacher und günstiger, Sicherheitslücken früh im Entwicklungsprozess zu erkennen und zu beheben, anstatt erst dann, wenn die Anwendung bereits in Produktion ist. Hier könnte ein ungeplanter Ausfall nämlich deine Benutzer(innen) beeinträchtigen und deinem Umsatz schaden.\n\nFolgende integrierte Sicherheitsscanner und Analysatoren sind in GitLab enthalten: Unit Tests, Infrastracture-as-Code-Scans (IaC), statische Anwendungssicherheitstests (SAST), Abhängigkeitssuche, Erkennung von Geheimnissen, Container-Scanning, API-Sicherheit, Web-API-Fuzzing und Abdeckungs-Fuzzing. Darüber hinaus hat GitLab eine Vielzahl an Sicherheitsdashboards und Berichten zu bieten, um Sicherheitslücken zu visualisieren. Dazu zählen die Liste der Abhängigkeiten, das Sicherheitsdashboard, der Sicherheitslückenbericht und die Sicherheitslücken-Seiten.\n\nUm Entwickler(inne)n und Security Engineers zu helfen, Sicherheitslücken besser zu verstehen und effizienter zu beheben, bietet die Funktion GitLab Duo **Vulnerability Explanation** eine Erklärung zu einer bestimmten Sicherheitslücke, wie sie ausgenutzt werden kann, und vor allem eine Empfehlung, wie die Sicherheitslücke behoben werden kann. Entwickler(innen) profitieren außerdem von der Funktion GitLab Duo **Vulnerability Resolution**, mit der automatisch ein Merge Request erstellt wird, der Codeänderungen zur Behebung der Sicherheitslücke enthält. Diese KI-basierten Funktionen tragen dazu bei, eine Anwendung sicherer zu machen und zu härten, um Sicherheitslücken zu vermeiden, die in der Produktion dann Ziel von Cyberangriffen werden könnten.\n\nNeben SAST-Scannern bietet GitLab auch DAST-Scanner (dynamische Anwendungssicherheitstest), für die eine laufende Anwendung erforderlich ist. Wenn diese Scanner eingesetzt werden, kann GitLab automatisch eine DAST-Umgebung für die DAST-Scans bereitstellen und dann nach dem DAST-Test eine komplette Bereinigung aller Ressourcen durchführen. Zudem bietet GitLab für ausgeführte Container das Operational Container Scanning (OCS) an, bei dem Container-Images in deinem Cluster auf Sicherheitslücken überprüft werden.\n\nDie genannten Scans können automatisch in einer Merge-Request-Pipeline ausgeführt werden. In einigen Fällen kann ihre Ausführung auch über Scan-Ausführungs- oder Merge-Request-Approvalrichtlinien geplant werden. Diese Richtlinien können über das GitLab-UI oder YAML-Dateien festgelegt werden und werden in einem separaten Projekt konfiguriert. Dies ermöglicht eine Aufgabentrennung, die die erneute Verwendung, die Wartung und die Verwaltung vereinfacht. Scan-Ausführungsrichtlinien erfordern, dass Sicherheitsscans nach einem bestimmten Zeitplan oder mit der Projektpipeline ausgeführt werden, während Merge-Request-Approvalrichtlinien Maßnahmen auf der Grundlage von Scan-Ergebnissen setzen. Security Engineers oder Sicherheitsteams können diese Richtlinien festlegen, um Sicherheitsprozesse im gesamten Unternehmen durchzusetzen. Da sich GitLab Flow durch alle Schritte zieht, können diese Richtlinien vorkommen bzw. genutzt werden.Um die Sicherheit und Compliance in deinem Unternehmen projektübergreifend durchzusetzen, kannst du Compliance-Labels und -Pipelines verwenden. Du kannst festlegen, dass Compliance-Labels und -Pipelines verpflichtend vor der eigenen Pipeline eines Projekts ausgeführt werden müssen. Mit diesem Ansatz kannst du sicherstellen, dass alle Teams in deinem Unternehmen deine Sicherheits- und Compliance-Standards erfüllen. Darüber hinaus kannst du so deine Anwendungen vor Cyberangriffen schützen, rechtlichen Vorgaben entsprechen und stets für Audits bereit sein.\n\nDas Hauptziel dieser Sicherheitsvorschriften von GitLab Flow ist, Sicherheitslücken früh im Entwicklungsprozess zu beheben, ehe die Anwendung in Produktion ist. Dann kann es nämlich sowohl teuer als auch schlecht für den Ruf sein, eine solche Sicherheitslücke beheben zu müssen.\n\nWenn Sicherheitslücken in der inneren Feedbackschleife von GitLab Flow behoben werden und weitere Updates an der Anwendung im Feature-Branch vorgenommen werden, müssen die Beteiligten auch diese Updates erneut überprüfen, um sicherzustellen, dass sie wirklich vorgenommen wurden und dass keine versehentlichen Regressionen eingeführt wurden.\n\n### Kontinuierlicher Review\n![Reviews – das vierte Element von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-reviewing-features-portion.png)\n\u003Ccenter>Reviews – das vierte Element von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nDas nächste Element von GitLab Flow ist der Review von Funktionen, also eine kontinuierliche Überprüfung von Anwendungen. Die Review-Funktionen umfassen die Möglichkeit, eine Review-Umgebung zu erstellen, in der die vorläufige Anwendung (der sogenannte Feature-Branch) bereitgestellt wird, damit die Beteiligten sie in Echtzeit überprüfen und ihr Feedback dazu abgeben können. Die vorläufige Anwendung kann dann kontinuierlich angepasst werden, bis sie mit dem Haupt-Branch zusammengeführt werden kann. GitLab Flow schreibt außerdem eine Bereinigung aller in der Review-Umgebung bereitgestellten Ressourcen zu dem Zeitpunkt vor, an dem der Merge Request mit dem Haupt-Branch zusammengeführt wird.\n\nDieser iterative automatisierte Review-Prozess ist Teil der inneren Feedbackschleife in GitLab Flow. Wie erwähnt ermöglichen in der inneren Feedbackschleife GitLab-Duo-Funktionen wie Codeerläuterungen, Codevorschläge, vorgeschlagene Prüfer(innen), Merge-Request-Zusammenfassungen, Erstellung von Vorlagen für Merge Requests, Code-Review-Zusammenfassungen, Erläuterungen von Sicherheitslücken, Behebung von Sicherheitslücken und Grundursachenanalyse in GitLab Flow eine bessere Übergabe zwischen Autor(inn)en und Prüfer(inne)n und optimieren den gesamten Review-Prozess.\n\nDie innere Feedbackschleife von GitLab Flow endet, wenn alle Review-Elemente behandelt wurden, der Merge Request freigegeben wurde und mit dem Haupt-Branch zusammengeführt wurde. Dies löst dann die Bereitstellung der Anwendung für die Produktion aus.\n\n### Bereitstellung von Anwendungen und Infrastrukturen\n\n![Bereitstellen – das fünfte Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-deploy-apps-portion.png)\n\u003Ccenter>Bereitstellen – das fünfte Element in GitLab Flow]\u003C/center>\u003Cp>\u003C/p>\n\nAbhängig von den Anforderungen eines Unternehmens gibt GitLab Flow entweder kontinuierliche Lieferung oder kontinuierliche Bereitstellung vor. Während man unter kontinuierlicher Lieferung die häufige Veröffentlichung von Code durch manuelles Auslösen der Bereitstellungen (z. B. in die Produktion) versteht, ist die kontinuierliche Bereitstellung die automatische Veröffentlichung von Code (z. B. in die Produktion) ohne menschliches Zutun. Sehen wir uns zunächst die kontinuierliche Lieferung an.\n\nWenn du deine Software mit kontinuierlicher Lieferung veröffentlichst, gibt es verschiedene Bereitstellungsoptionen. Du kannst ein Standbild-Fenster einrichten und dann mit fortschrittlichen Bereitstellungstechniken wie Canary, Blue/Green, zeitlich abgestimmte und inkrementelle Rollouts bereitstellen. Inkrementelle Rollouts können das Risiko von Produktionsausfällen verringern, was zu einer besseren User Experience und einer höheren Kundenzufriedenheit führt. Fortschrittliche Bereitstellungstechniken können auch die Entwicklungs- und Liefereffizienz verbessern und den Release-Prozess optimieren.\n\nWenn du deine Software mit kontinuierlicher Bereitstellung veröffentlichst, gehen alle Änderungen/Updates direkt in die Produktion. Progressive Bereitstellungsansätze wie Feature-Flags, mit denen du die Bereitstellung bestimmter Funktionen von einer Markteinführung trennen kannst, sind eine gute Möglichkeit, die Risiken zu reduzieren und zu verwalten, welche Funktionen den Produktionsbenutzer(inne)n zur Verfügung gestellt werden sollen. Feature-Flags unterstützen mehrere Programmiersprachen und ermöglichen Experimente der Entwickler(innen) und kontrollierte Tests. Du kannst sogar Feature-Flags verwenden, um Funktionen nur für bestimmte Benutzer(innen) auszurollen.\n\nGitLab unterstützt all diese Bereitstellungsansätze, doch GitLab Flow ermöglicht nur die Umsetzung jenes Ansatzes, der am besten zum Unternehmen und/oder zum spezifischen Projekt passt.\n\n### Überwachen von Anwendungen und DevSecOps-Prozessen\nSobald deine Anwendung für die Produktion bereitgestellt wurde, muss sie kontinuierlich überwacht werden, um ihre Stabilität, Leistung und Verfügbarkeit sicherzustellen. Darüber hinaus werden DevSecOps-Prozesse gemessen, während sie ausgeführt werden, damit ihre Leistung und Effizienz verbessert werden kann. Diese Überwachungsfunktionen werden von GitLab bereitgestellt und können daher auch mit GitLab Flow genutzt werden.\n\nGitLab bietet für ausgeführte Container das Operational Container Scanning (OCS) an, bei dem Container-Images in deinem Cluster auf Sicherheitslücken überprüft werden. Diese Scans können automatisiert werden, indem du planst, wann sie ausgeführt werden. Gefundene Sicherheitslücken werden dann automatisch in einem Sicherheitsdashboard angezeigt. Das OCS hilft dir dabei, deine Cluster-Anwendungen zu schützen und Cyberangriffe, die zur Veröffentlichung privater Daten und sogar zu unerwarteten Ausfällen führen können, frühzeitig abzuwehren.\n\nDie Fehlerverfolgung ermöglicht es Entwickler(inne)n, von ihrer Anwendung generierte Fehler zu entdecken und anzuzeigen. Alle von deiner Anwendung generierten Fehler werden in der Fehlerverfolgungsliste in GitLab angezeigt. Die Fehlerverfolgung trägt zu einer besseren Verfügbarkeit und Leistung deiner Anwendungen bei, indem unerwartete Anwendungsbedingungen schnell erkannt und behoben werden.\n\nGitLab kann über einen Webhook-Empfänger Alarme von beliebigen Überwachungsquellen wie Prometheus erhalten. Wenn Alarme eingehen, werden sie in der GitLab-Alarmliste angezeigt, von wo aus du sie dann manuell verwalten kannst. Alarme können auch automatisch die Erstellung von Vorfällen, ChatOps und E-Mails an die entsprechenden Personen oder Gruppen auslösen. All diese Funktionen optimieren den Umgang mit Alarmen sowie deren Bearbeitung.\n\nWenn Vorfälle aufgrund von Produktionsproblemen erstellt werden, werden sie in der GitLab-Vorfall-Liste für das Vorfallmanagement angezeigt. Du kannst einen oder mehrere Vorfälle verwalten, sie sortieren, durchsuchen, zuweisen, ihren Status festlegen und sogar den vorab gesetzten SLA-Countdown-Timer anzeigen. Darüber hinaus kannst du Bereitschaftspläne und -rotationen erstellen, Eskalationsrichtlinien festlegen sowie Paging und Benachrichtigungen für die Bearbeitung von Vorfällen einrichten. Außerdem kannst du einen Vorfall mit einem Alarm verknüpfen. Wenn der Vorfall geschlossen wird, wird der zugehörige Alarm automatisch als gelöst gekennzeichnet. Vorfall-Zeitleisten sind eine weitere Funktion für Führungskräfte und externe Betrachter(innen), um zu sehen, was während eines Vorfalls passiert ist und welche Maßnahmen zur Behebung des Vorfalls getroffen wurden. All diese Funktionen optimieren das Vorfallmanagement, damit Vorfälle so schnell wie möglich gelöst werden können.\n\nAudit Events verfolgen wichtige Ereignisse und zeichnen unter anderem auf, wer die entsprechende Handlung zu welchem Zeitpunkt in GitLab ausgeführt hat. Diese Ereignisse werden in der Audit-Event-Liste in GitLab angezeigt und geben unter anderem Informationen zum Ereignis, das für ein Objekt durchgeführt hatte, sowie die Person, die dieses Ereignis durchgeführt hat, und Datum und Uhrzeit.\n\nAll diese Listen und Dashboards helfen, nicht konforme Szenarien und damit zusammenhängende Strafen früh genug zu vermeiden sowie Audit-Prozesse zu optimieren. Sie generieren Daten und Indikatoren für deine laufenden Anwendungen, die dann in der äußeren Feedbackschleife von GitLab Flow verwendet werden können, um deine Anwendungen zu verbessern und zu optimieren und das Risiko unerwarteter Produktionsausfälle zu verringern.\n\n### Kontinuierliche Verbesserung\nWenn du GitLab Flow einsetzt, hast du auch die Möglichkeit, Einblicke mit GitLab zu nutzen. Du erhältst diese in Form von durchgängigen Prozessmetrik-Dashboards, damit du nicht nur deine Anwendungen, sondern auch die Performance deiner Softwarebereitstellung kontinuierlich verbessern kannst. Diese Dashboards und ihre Metriken werden von GitLab automatisch generiert und sind immer verfügbar.\n\n### Dashboard für die Wertstromanalyse\nDu kannst den Lebenszyklus deiner Anwendungsentwicklung über das Dashboard für die Wertstromanalyse verfolgen und überwachen, denn hier kannst du Projekt- und Gruppenstatistiken im Zeitverlauf anzeigen. Dieses Dashboard ist anpassbar, du kannst aber auch gleich loslegen und eine Wertschöpfungskette über eine der vorgefertigten Vorlagen von GitLab erstellen. Das Standarddashboard zeigt Metriken für jede der vordefinierten Phasen deiner Wertstromanalyse an, also Ticket, Planen, Programmieren, Testen, Review und Staging. Außerdem wird ein Diagramm mit der durchschnittlichen Zeit, die für den Abschluss der einzelnen Phasen benötigt wird, angezeigt. Hier werden auch die wichtigsten Indikatoren der Wertstromanalyse angezeigt: Abarbeitungsdauer, Bearbeitungszeit, neue Tickets, Commits und Bereitstellungen. Du kannst anhand dieser Metriken Verbesserungsbereiche in den einzelnen Phasen deiner Wertschöpfungskette identifizieren.\n\n### DORA-Metrik-Dashboard\nUm die Performance-Metriken anzuzeigen, die die Effektivität der Entwicklung und der Bereitstellungspraktiken in deinem Unternehmen messen, gibt es in GitLab das [DORA-Metrik-Dashboard](https://about.gitlab.com/de-de/solutions/value-stream-management/dora/) (DevOps Research and Assessment), in dem vier wichtige Metriken angezeigt werden: Häufigkeit der Bereitstellung, Vorlaufzeit für Änderungen, Zeit bis zur Wiederherstellung des Service und Änderungsfehlerrate. Die Häufigkeit der Bereitstellung misst, wie oft dein Unternehmen Code in der Produktion bereitstellt oder für Endbenutzer(innen) veröffentlicht. Die Vorlaufzeit für Änderungen misst, wie lange es vom Commiten des Codes bis zur erfolgreichen Ausführung in der Produktion dauert. Die Zeit bis zur Wiederherstellung des Service misst die Zeit, die benötigt wird, um die Services bei einem Vorfall auf dem vorherigen Niveau wiederherzustellen. Die letzte Kennzahl ist die Änderungsfehlerrate, also der Prozentsatz an Änderungen an der Produktion bzw. an für Benutzer(innen) veröffentlichten Anwendungen, die zu einem eingeschränkten Service führen (z. B. durch eine Änderung, die zu einer Einschränkung des Service oder zu einem Ausfall führte) und dementsprechende Behebung benötigen (in Form von Hotfixes, Rollbacks oder Patches). Diese vier Schlüsselkennzahlen sind Ergebnisse deine aktuellen Prozesse und geben dir die Möglichkeit, die Faktoren und Funktionen zu verbessern, die dahinterstehen.\n\n### Anpassung deines Dashboards\nEin weiteres Dashboard ist das Wertstrom-Dashboard, ein anpassbares Dashboard, mit dem Entscheidungsträger(innen) Trends, Muster und Möglichkeiten für Verbesserungen im Bereich der Softwareentwicklung erkennen können. Die gezeigten Metriken sind die DORA-Metriken, gefolgt von Flow-Metriken für die Wertstromanalyse und Zähler für kritische und hohe Sicherheitslücken im jeweiligen Monat bis zum aktuellen Datum, für die zwei vorhergehenden Monate sowie die sechs vorhergehenden Monate.\n\nGitLab Duo kann auch bei deinen Bestrebungen für kontinuierliche Verbesserungen helfen. Die Funktion **Wertstromprognose** zieht historische Daten heran und verwendet Datentrends aus deinem gesamten Entwicklungslebenszyklus, um das zukünftige Verhalten deiner Wertstrom-Metriken zu prognostizieren. Du kannst diese prädiktiven Analysen für deine Optimierungen nutzen.\n\nAll diese Dashboards und die Indikatoren, die sie anzeigen, sind Teil der äußeren Feedbackschleife von GitLab Flow. Sie helfen dir, das Risiko ungeplanter Produktionsausfälle zu verringern sowie deine Anwendungen und DevSecOps-Workflows zu verbessern.\n\n### KI-Impact-Analysen\nUm die Auswirkungen von GitLab Duo (bzw. der KI) im gesamten Entwicklungslebenszyklus besser zu verstehen, steht dir die [KI-Impact-Analyse](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) zur Verfügung. Hier siehst du, wie sich die Nutzung von Codevorschlägen von GitLab Duo auf andere Leistungs-, Qualitäts- und Sicherheitsmetriken auswirkt. Du kannst die letzten sechs Monate der KI-Einführung und ihre Auswirkungen auf andere Indikatoren wie Bearbeitungszeit, Abarbeitungsdauer, Bereitstellungshäufigkeit, Änderungsfehlerrate und kritische Sicherheitslücken im Zeitverlauf visualisieren.\n\nKI-Impact-Analysen helfen dir dabei, die Akzeptanz, Effektivität und Vorteile zu messen, die die KI deinen Teams und deinem Unternehmen bringt. Zudem tragen sie dazu bei, Verbesserungsbereiche zu identifizieren.\n\n## Warum solltest du GitLab Flow verwenden?\nGitLab Flow ist ein vorgefertigter Ansatz, der von unseren Kund(inn)en und Benutzer(inne)n auf der ganzen Welt eingesetzt wird und folgende Vorteile bieten kann:\n\n- Höhere Produktivität durch Automatisierungsmöglichkeiten von GitLab und dessen vereinheitlichter Benutzeroberfläche und des einheitlichen Datenmodells, die beide von GitLab Flow verwendet werden\n- Genaue Einblicke in den gesamten DevSecOps-Lebenszyklus, um kontinuierliche Verbesserungen zu ermöglichen\n- Integrierte Dashboards und Metriken, die dir dabei helfen, deine Anwendungen und DevSecOps-Prozesse zu optimieren\n- Höhere Codequalität und verbesserte Zuverlässigkeit und Verfügbarkeit deiner Anwendungen\n- Bessere Anwendungssicherheit durch integrierte Sicherheitsscanner und -funktionen\n- Einhaltung von Compliance und Vorbereitung für Audits durch integrierte Compliance-Funktionen\n- Kürzere Bearbeitungszeiten für höhere Bereitstellungshäufigkeit\n- Kontinuierliche Reviews durch die innere Feedbackschleife von GitLab Flow\n- Die innere Feedbackschleife von GitLab Flow hilft dir, Anwendungs-Updates zu optimieren, wodurch sich die Codequalität verbessert und deine Anwendungen zuverlässiger und besser verfügbar werden\n- Die äußere Feedbackschleife von GitLab Flow kann dazu beitragen, deine Anwendungen sowie den Entwicklungslebenszyklus an sich zu verbessern\n- Intensive Zusammenarbeit zwischen den Beteiligten in deinem Unternehmen\n- Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den Anwendungen zu finden,  bevor sie in die Produktion gelangen, wo solche Fehler teure, ungeplante Ausfälle verursachen können - Niedrigeres Risiko bei der Bereitstellung in die Produktion durch fortschrittliche Bereitstellungstechnicken und den progressiven Lieferansatz von GitLab\n- KI-Funktionen im gesamten Entwicklungslebenszyklus können Produktivität, Codequalität, kontinuierliche Verbesserung, Sicherheit, Compliance und mehr verbessern\n- Unterstützung für Cloud-native und nicht-Cloud-native Anwendungen\n- Multi-Cloud-Support für hybride Anwendungen und Multi-Cloud-Anwendungen\n- Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den Anwendungen zu finden, bevor sie in die Produktion gelangen, wo solche Fehler teure, ungeplante Ausfälle verursachen können\n\nWie kannst du mit GitLab Flow durchstarten? Ein guter Ausgangspunkt, um die Prinzipien von GitLab Flow für deinen Lebenszyklus der Anwendungsentwicklung einzuführen, sind Auto-DevOps von GitLab.\n\n## GitLab Flow und Auto-DevOps\n\n![Auto DevOps – eine Instanziierung von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/ado-pipeline.png)\n\u003Ccenter>Auto-DevOps – eine Instanziierung von GitLab Flow\u003C/center>\u003Cp>\u003C/p>Bei [Auto-DevOps](https://docs.gitlab.com/topics/autodevops/) wird GitLab Flow in allen Phasen und Jobs angewendet. Du kannst es dir als ein gutes Beispiel für die Instanziierung von GitLab Flow vorstellen.\n\nAuto-DevOps ist eine Sammlung vordefinierter, sofort einsatzbereiter CI/CD-Vorlagen, die deinen Quellcode automatisch erkennen. Basierend auf bewährten Methoden können diese Vorlagen deine Anwendungen automatisch erkennen, erstellen, testen, bereitstellen und überwachen.\n\nDie Auto-DevOps-Pipeline kontrolliert die Sicherheit im Vorfeld, um Fehler so früh wie möglich im Softwarelieferprozess zu finden und zu vermeiden. Die Pipeline stellt die Anwendung dann zur Verifizierung im Staging und dann inkrementell/zeitgesteuert in der Produktion bereit.\n\nMit Auto-DevOps kannst du rasch durchstarten, die Produktivität der Entwickler(innen) steigern und das Ganze einfach an deine Bedürfnisse anpassen. Außerdem erhältst du Unterstützung für die bekanntesten Programmier-Frameworks und -sprachen. Auto-DevOps ist modular, anpassbar und erweiterbar, sodass du sowohl nur einzelne Elemente in deiner Pipeline nutzen oder das Gesamtpaket für deine Anwendung einsetzen kannst.\n\n## Los geht’s\n[Kombiniere jetzt GitLab Flow und GitLab Duo](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F), um die Effizienz deiner Workflows von Anfang bis Ende deutlich zu verbessern. So kannst du eine noch höhere Produktivität, Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie verbesserte Resilienz und Verfügbarkeit deiner Produktion erreichen.\n\nWenn du sehen möchtest, wie ein Workflow funktioniert, der GitLab Flow und GitLab Duo kombiniert und wie du davon profitieren kannst, schau dir das folgende Video an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/CKrZ4_tKY4I?si=Kf6QsYFIzKkJZpJd\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n","ai-ml",{"slug":13,"featured":14,"template":15},"gitlab-flow-duo",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21,"updatedDate":25},"Erweitere GitLab Flow um die KI-basierten Funktionen von GitLab Duo, um deine DevSecOps-Workflows so effizient wie noch nie zuvor zu machen (Tutorial mit Video).",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","2023-07-27",[22,23,24],"CI/CD","AI/ML","DevSecOps","2025-04-21","yml",null,{},true,"/de-de/blog/gitlab-flow-duo","seo:\n  title: 'Kombiniere GitLab Flow und GitLab Duo für starke Workflows'\n  description: 'Erweitere GitLab Flow um die KI-basierten Funktionen von\n    GitLab Duo, um deine DevSecOps-Workflows so effizient wie noch nie zuvor zu\n    machen (Tutorial mit Video).'\n  ogTitle: 'Kombiniere GitLab Flow und GitLab Duo für starke Workflows'\n  ogDescription: 'Erweitere GitLab Flow um die KI-basierten Funktionen von\n    GitLab Duo, um deine DevSecOps-Workflows so effizient wie noch nie zuvor zu\n    machen (Tutorial mit Video).'\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png\n  ogUrl: https://about.gitlab.com/blog/gitlab-flow-duo\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/gitlab-flow-duo\ncontent:\n  title: 'Kombiniere GitLab Flow und GitLab Duo für starke Workflows'\n  description: 'Erweitere GitLab Flow um die KI-basierten Funktionen von\n    GitLab Duo, um deine DevSecOps-Workflows so effizient wie noch nie zuvor zu\n    machen (Tutorial mit Video).'\n  authors:\n    - Cesar Saavedra\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png\n  date: '2023-07-27'\n  body: \"Für den Einstieg in DevSecOps ist ein gut durchdachter Workflow nötig –\n    doch das kann oft eine echte Herausforderung sein. Zum Glück gibt es zwei\n    Dinge, die dir dabei helfen können:\\\n\n\n    **GitLab Flow und GitLab Duo.**\n\n\n    GitLab Flow ist ein vorgefertigter Ansatz, der Unternehmen dabei hilft,\n    DevSecOps-Prozesse erfolgreich umzusetzen. GitLab Duo ist ein\n    [leistungsstarkes Set an KI-basierten\n    Funktionen](https://about.gitlab.com/blog/supercharge-productivity-with-git\\\n    lab-duo/) in der DevSecOps-Plattform von GitLab, das Unternehmen dabei\n    helfen kann, Code zu entwickeln, den Betrieb zu optimieren und Software\n    effizienter zu schützen. Zusammen helfen GitLab Flow und GitLab Duo\n    Unternehmen dabei, die Effizienz ihrer Workflows durchgängig deutlich zu\n    verbessern. Das führt dann zu noch höherer Produktivität,\n    Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie zu Resilienz\n    und Verfügbarkeit der Produktion.\n\n\n    In diesem Artikel erfährst du, wie GitLab Flow und GitLab Duo zusammen dazu\n    beitragen können, Unternehmen mit DevSecOps zum Erfolg zu führen.\n\n\n    \\ > Entdecke die Zukunft von KI-gestützter Softwareentwicklung mit unserem\n    virtuellen Launch-Event zu GitLab 17.  [Jetzt\n    ansehen!](https://about.gitlab.com/de-de/eighteen/)\n\n\n    ## Was ist GitLab Flow?\n\n    GitLab Flow ist ein vorgefertigter, festgelegter und durchgängiger Workflow\n    für den Entwicklungslebenszyklus von Anwendungen mit GitLab, einer\n    KI-basierten DevSecOps-Plattform, die eine einheitliche Benutzeroberfläche\n    und ein einheitliches Datenmodell bietet. GitLab Flow baut auf bewährten\n    Methoden und Erfahrungen aus Kundenfeedback und unserem Dogfooding auf.\n    Außerdem deckt GitLab Flow alle [Phasen des\n    DevSecOps-Lebenszyklus](https://about.gitlab.com/de-de/stages-devops-lifecy\\\n    cle/) ab und ermöglicht so einen effizienten Workflow, der aus einer inneren\n    Feedbackschleife für Reviews bestimmter Updates sowie einer äußeren\n    Feedbackschleife für die Verbesserung der gesamten Anwendung sowie des\n    Entwicklungsprozesses an sich besteht.\n\n\n    ![Innere und äußere Feedbackschleifen von\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-feedback-loops.png)\n\n    \u003Ccenter>Innere und äußere Feedbackschleifen von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n\n    Wie du an den vielen Phasen in GitLab Flow erkennen kannst, besteht die\n    Entwicklung einer Software aus viel mehr als dem reinen Programmieren. Im\n    Folgenden erfährst du mehr über jeden Schritt von GitLab Flow und darüber,\n    wie GitLab Duo dich dabei unterstützen kann.\n\n\n    ### Planen\n\n    Das erste Element von GitLab Flow ist die Planung, die sich in der äußeren\n    Feedbackschleife von GitLab Flow befindet. Sie umfasst Tickets, Merge\n    Requests, Epics, Meilensteine, Iterationen, Veröffentlichungen,\n    Release-Nachweise und mehr. Im Folgenden erfährst du, welche Rolle diese\n    Komponenten in GitLab Flow spielen und wie dich GitLab Duo dabei\n    unterstützen kann.\n\n\n    ![Planen – das erste Element in\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-planning-portion.png)\n\n    \u003Ccenter>Planen – das erste Element in GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n\n    #### Tickets\n\n    Tickets sind die Elemente, in denen Produktprobleme oder neue Funktionen\n    definiert werden und in denen Teammitglieder zusammenarbeiten können. Wenn\n    ein Ticket erstellt wird, kannst du seinen Titel ausfüllen und dann die\n    Funktion GitLab Duo **Issue Description Generation** nutzen, um die\n    Beschreibung zu erstellen. So sparst du Zeit und hast weniger Aufwand. Da\n    viele Beteiligte an Kommentar-Threads in einem Ticket mitarbeiten können,\n    ist die **Diskussionszusammenfassung** eine KI-basierte Funktion von\n    GitLab Duo, die dir hunderte Kommentare zu einem Ticket in einem kurzen\n    Absatz zusammenfasst. So erhalten die Beteiligten rasch einen Überblick über\n    die Konversation, können sich direkt an der Diskussion beteiligen und sofort\n    produktiv werden.\n\n\n    Tickets können in Issue-Übersichten organisiert und visualisiert werden.\n    Dabei handelt es sich um ein Software-Projektmanagementtool, das als Kanban-\n    oder Scrum-Board eingesetzt werden kann. Mit diesen Boards können Teams den\n    Workflow einer Funktion oder einer Produkt-Release einfacher planen,\n    organisieren und visualisieren. Es können verschiedene Kategorien von Boards\n    erstellt werden, wobei Tickets ganz einfach per Drag & Drop von einem zum\n    anderen gezogen werden können.\n\n\n    #### Merge Requests\n\n    Merge Requests sind die Elemente, in denen Lösungen entwickelt werden.\n    Tickets und Merge Requests sind Bestandteile einer Release und ermöglichen,\n    dass Änderungen an Anwendungen, die von Beteiligten wie DevOps und Platform\n    Engineers, System- und Datenbankadministrator(innen), Security Engineers und\n    Entwickler(inne)n vorgenommen werden, überprüft und nachverfolgt werden\n    können. Darüber hinaus sind Tickets und Merge Requests wichtige Inputs für\n    den Release-Planungsprozess.\n\n\n    Merge Requests können einzeln oder aus einem Ticket erstellt werden. Wenn du\n    ein Merge Request aus einem Ticket erstellst, wird es automatisch dem Ticket\n    zugeordnet. Wenn der Merge Request dann zusammengeführt wird, wird das\n    zugehörige Ticket automatisch geschlossen. Merge Requests können auch\n    manuell mit einem Ticket verknüpft werden.\n\n\n    ![Der Merge Request schließt das\n    Ticket](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/mr-with-\\\n    its-issue.png)\n\n    \u003Ccenter>Der Merge Request schließt das Ticket\u003C/center>\u003Cp>\u003C/p>\n\n\n    Ähnlich wie Tickets können auch Merge Requests eine lange Liste an Updates\n    an einem Feature-Branch, die durch verschiedene Beteiligte vorgenommen\n    wurden, enthalten. Mitwirkende, die sich mit den Updates vertraut machen\n    möchten oder alle Updates in einem Merge Request verstehen müssen, können\n    die Funktion **Merge-Request-Zusammenfassung** in GitLab Duo nutzen, um\n    einen raschen Überblick über die Änderungen zu erhalten. Darüber hinaus\n    können die Mitwirkenden mit der Funktion GitLab Duo **Code Merge Request\n    Template Population** eine vorab erstellte Merge-Request-Vorlage\n    heranziehen, die automatisch mit den entsprechenden Inhalten ausgefüllt\n    wird. Beschreibungsvorlagen sind eine Möglichkeit, die Zusammenarbeit und\n    Kommunikation im gesamten Entwicklungslebenszyklus zu standardisieren und zu\n    optimieren – und mit GitLab Duo geht das noch schneller!\n\n\n    Tickets mit demselben Thema können in einem Epic gruppiert werden, um die zu\n    erledigenden Arbeiten zu organisieren. Epics können untergeordnete Tickets\n    und Sub-Epics haben und/oder mit anderen Epics im gesamten Unternehmen\n    verknüpft werden. Mit Iterationen können Sprints nachverfolgt werden, und\n    sie können manuell oder mithilfe von Iterationskadenzen automatisch geplant\n    werden, um die Planungs-Workflows zu optimieren. Außerdem umfassen\n    Iterationen Abarbeitungs- und Burnup-Diagramme. Abarbeitungsdiagramme helfen\n    dabei, den Gesamtfortschritt im Projektumfang nachzuverfolgen, während\n    Burnup-Diagramme die tägliche Anzahl und Gewichtung von Tickets messen, die\n    in einer bestimmten Timebox hinzugefügt und abgeschlossen wurden.\n\n\n    #### Meilensteine\n\n    Mithilfe von Meilensteinen können Teams ihre Tickets und Merge Requests in\n    einer zusammenhängenden Gruppe mit optionalem Start- und Fälligkeitsdatum\n    organisieren. Meilensteine werden in der Regel verwendet, um Releases\n    nachzuverfolgen. Außerdem kann man mit ihnen Tickets und Merge Requests auf\n    Projekt- oder Gruppenebene nachverfolgen. Ähnlich wie Iterationen gibt es\n    auch bei Meilensteinen Abarbeitungs- und Burnup-Diagramme, die den\n    Fortschritt zeigen.\n\n\n    Meilensteine können mit einer Release verknüpft werden, bei deren Erstellung\n    automatisch Artefakte wie etwa ein Release-Nachweis erstellt werden. Der\n    Release-Nachweis ist eine automatisch gesammelte Momentaufnahme der Daten,\n    die mit dieser Release zusammenhängen. Neben Testartefakten und verknüpften\n    Meilensteinen kann der Release-Nachweis auch Jobartefakte enthalten, die\n    sich auf interne Prozesse wie externe Audits beziehen.\n\n\n    Epics, Meilensteine und Iterationen können über Roadmaps visualisiert\n    werden, die dir dabei helfen, den Release-Fortschritt nachzuverfolgen und\n    den Release-Prozess zu optimieren.\n\n\n    Sobald die Planung erfolgt ist, können die Arbeiten beginnen, die für die\n    Lösung eines Problems oder die Entwicklung einer neuen Funktion erforderlich\n    sind. Dies geschieht in Merge Requests. Im Folgenden erfährst du, wie das in\n    GitLab Flow funktioniert.\\\n\n\n    > [Erfahre mehr, indem du GitLab Flow und GitLab Duo\n    ausprobierst](https://gitlab.com/-/trials/new?glm_content=default-saas-tria\\\n    l&glm_source=about.gitlab.com%2Fblog%2F).\n\n\n    ### Merge Requests und Pushen von Code\n\n\n    ![Merge Requests und Pushen von Code – das zweite Element in\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-mr-pushing-code-portion.png)\n\n    \u003Ccenter>Merge Requests und Pushen von Code – das zweite Element in\n    GitLab Flow \u003C/center>\u003Cp>\u003C/p>\n\n\n    Das zweite Element von GitLab Flow betrifft Merge Requests und das Pushen\n    von Code. Wie bereits erwähnt sind Merge Requests jene Orte, an denen die\n    Beteiligten in einem Unternehmens an Lösungen zusammenarbeiten. Diese\n    Zusammenarbeit kann verteilt und asynchron erfolgen. Die Mitwirkenden können\n    die Kooperationsfunktionen wie Tagging, Inline-Vorschläge,\n    Inline-Kommentare, Merge-Request-Kommentare, Review Threads und Review\n    Requests nutzen, um gemeinsam die Codequalität, Verfügbarkeit,\n    Zuverlässigkeit und Leistung zu verbessern. Direkt nach der Erstellung eines\n    Merge Requests beginnt die innere Feedbackschleife von GitLab Flow, in der\n    Code, Fix-Pushes, Tests und Scans durchgeführt werden. Hier finden außerdem\n    Reviews zur Zusammenarbeit und zu Updates statt.\n\n\n    #### Pipelines\n\n    Wenn Updates über Merge Requests auf einen Feature-Branch angewendet werden,\n    werden automatisch Pipelines ausgeführt, falls diese vorab festgelegt\n    wurden. Pipelines können mehrere Phasen und Jobs haben, um die Anwendung\n    oder den Microservice in einer Review-Umgebung zu erstellen, zu testen und\n    dann bereitzustellen. In dieser Review-Umgebung können Updates dynamisch\n    verifiziert werden, bevor sie in den Haupt-Branch zusammengeführt werden.\n    Diese Automatisierung trägt dazu bei, den Update- und Review-Prozess von\n    Anwendungen zu optimieren.\n\n\n    Zudem stellen DevSecOps-Teams, die über Merge Requests Updates an\n    Anwendungen vornehmen, eine Vielzahl an KI-basierten Funktionen zur\n    Verfügung. Wenn sie Code schreiben oder aktualisieren, kann GitLab Duo\n    **Codevorschläge** Code empfehlen, der an dieser Stelle passen würde, und\n    die Entwickler(innen) können entscheiden, ob sie diese Empfehlung annehmen\n    oder ignorieren möchten. Codevorschläge unterstützen dich bei der\n    Codeerstellung über Prompts sowie durch die Code-Vervollständigung, die\n    angezeigt wird, während du schreibst. Codevorschläge können das\n    Programmiererlebnis verbessern, indem sie Fehler reduzieren und es den\n    Entwickler(inne)n ermöglichen, schneller Code zu schreiben. Dies trägt\n    wiederum dazu bei, die Qualität des Produktionscodes zu verbessern.\n    Codevorschläge können außerdem zu einer höheren Produktivität der\n    Entwickler(innen) und schnelleren Iterationen und Rollouts führen.\n\n\n    Da verschiedene Stakeholder innerhalb der Organisation an der Entwicklung\n    oder Überprüfung von Anwendungen beteiligt sind, können sie auf Code stoßen,\n    der schlecht dokumentiert, komplex oder schwer zu verstehen ist oder in\n    einer ihnen unbekannten Programmiersprache geschrieben ist. Die Funktion\n    **Codeerläuterung** von GitLab Duo erklärt den Code in natürlicher Sprache,\n    sodass jeder den Code verstehen und schnell auf dem neuesten Stand sein\n    kann.\n\n\n    Wenn Aktualisierungen in den Feature-Branch committet werden, verwendet die\n    GitLab-Duo-Funktion **Vorgeschlagene Prüfer(innen)** die Änderungen in einem\n    Merge Request und das Mitarbeiterdiagramm eines Projekts, um geeignete\n    Prüfer(innen) im Dropdown in der Seitenleiste des Merge Request\n    vorzuschlagen. Die Liste enthält Benutzer(innen), die sich mit einem\n    bestimmten Aspekt der Anwendung auskennen und daher am besten dazu geeignet\n    sind, die Updates zu überprüfen. Entwickler(innen) sparen Zeit, da sie die\n    am besten geeignet Prüfer(innen) nicht suchen und identifizieren müssen\n    sowie den Überprüfungsprozess rationalisieren und Verzögerungen und Reviews\n    von geringer Qualität vermeiden können.Wenn Entwickler(innen) Änderungen am\n    Code vornehmen, fügen sie im Merge Request oft keine Kommentare zu den\n    spezifischen Änderungen hinzu, die sie vorgenommen haben. Mit der\n    **Merge-Request-Zusammenfassung** von GitLab Duo kann die bzw. der Autor(in)\n    von Merge-Request-Änderungen mithilfe der KI einen Kommentar in natürlicher\n    Sprache generieren, der die Updates am Code zusammenfasst. Prüfer(innen)\n    können dann die Änderungen besser verstehen und den gesamten\n    Überprüfungsprozess optimieren.\n\n\n    Wenn Prüfer(innen) Updates des Codes in einem Merge Request überprüfen,\n    können sie den Merge Request blockieren. Die Begründung kann aus vielen\n    Kommentaren bestehen, die sich über viele Quelldateien erstrecken. Um der\n    bzw. dem ursprünglichen Autor(in) der Updates zu helfen, das Feedback der\n    Prüferin oder des Prüfers in einem langen Block besser zu verstehen,\n    erstellt die **Code-Review-Zusammenfassung** von GitLab Duo eine\n    Zusammenfassung des Feedbacks der Prüferin bzw. des Prüfers in natürlicher\n    Sprache. Dies ermöglicht eine bessere Übergabe zwischen Autor(inn)en und\n    Prüfer(inne)n, wodurch der Review-Prozess optimiert wird.\n\n\n    Wenn Entwickler(innen) neuen Code über einen Merge Request hinzufügen,\n    können sie außerdem die **Testgenerierung** von GitLab Duo nutzen, die\n    mithilfe von KI Unit-Tests für den neuen Code generiert. Dies kann dazu\n    beitragen, die Produktivität der Entwickler(innen) zu erhöhen, die\n    Testabdeckung zu verbessern und Fehler frühzeitig im\n    Entwicklungslebenszyklus zu erkennen. Entwickler(innen) können auch den\n    jederzeit verfügbaren **Chat** von GitLab Duo nutzen, um Code zu\n    refaktorisieren und Inline-Dokumentation wie z. B. Docstrings für ihren\n    Quellcode erstellen.\n\n\n    Pipelines werden auf Branch-Updates ausgeführt und können automatisierte\n    Tests und Scans enthalten, die dazu beitragen, die Sicherheit schon im\n    Vorfeld zu kontrollieren.\n\n\n    ### Sicherheit im Vorfeld kontrollieren (Shift-Left-Ansatz)\n\n\n    ![Sicherheit im Vorfeld kontrollieren – das dritte Element von\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-shift-sec-left-portion.png)\n\n    \u003Ccenter>Sicherheit im Vorfeld kontrollieren – das dritte Element von\n    GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n\n    Das dritte Element von GitLab Flow ist, dass die Sicherheit im Vorfeld\n    kontrolliert wird. Diese Kontrolle ist auch Teil der inneren\n    Feedbackschlaufe von GitLab Flow.\n\n\n    Neben DevOps und Platform Engineers, System- und\n    Datenbankadministrator(innen) und Entwickler(innen) betrifft die Sicherheit\n    und Compliance auch einige der Beteiligten, die in einem Merge Request\n    zusammenarbeiten, also an einem Ort, an dem automatisierte Tests und\n    Sicherheitsscans eine Rolle spielen. Scans können einfach über praktisch\n    nutzbare Vorlagen in eine Pipeline aufgenommen werden und/oder automatisch\n    in einer Merge-Request-Pipeline ausgeführt werden. GitLab bietet eine Reihe\n    an integrierten Sicherheitsscannern und Analysatoren, die von GitLab Flow\n    genutzt werden können, doch auf der DevSecOps-Plattform sind auch Scanner\n    von Drittanbietern sowie benutzerdefinierte Scanner möglich.\n\n\n    GitLab Flow kontrolliert die Sicherheit im Vorfeld und verschiebt sie an den\n    Anfang der Pipeline, um Fehler so früh wie möglich im\n    Softwareentwicklungsprozess zu erkennen und zu beheben. Es ist viel\n    einfacher und günstiger, Sicherheitslücken früh im Entwicklungsprozess zu\n    erkennen und zu beheben, anstatt erst dann, wenn die Anwendung bereits in\n    Produktion ist. Hier könnte ein ungeplanter Ausfall nämlich deine\n    Benutzer(innen) beeinträchtigen und deinem Umsatz schaden.\n\n\n    Folgende integrierte Sicherheitsscanner und Analysatoren sind in GitLab\n    enthalten: Unit Tests, Infrastracture-as-Code-Scans (IaC), statische\n    Anwendungssicherheitstests (SAST), Abhängigkeitssuche, Erkennung von\n    Geheimnissen, Container-Scanning, API-Sicherheit, Web-API-Fuzzing und\n    Abdeckungs-Fuzzing. Darüber hinaus hat GitLab eine Vielzahl an\n    Sicherheitsdashboards und Berichten zu bieten, um Sicherheitslücken zu\n    visualisieren. Dazu zählen die Liste der Abhängigkeiten, das\n    Sicherheitsdashboard, der Sicherheitslückenbericht und die\n    Sicherheitslücken-Seiten.\n\n\n    Um Entwickler(inne)n und Security Engineers zu helfen, Sicherheitslücken\n    besser zu verstehen und effizienter zu beheben, bietet die Funktion\n    GitLab Duo **Vulnerability Explanation** eine Erklärung zu einer bestimmten\n    Sicherheitslücke, wie sie ausgenutzt werden kann, und vor allem eine\n    Empfehlung, wie die Sicherheitslücke behoben werden kann. Entwickler(innen)\n    profitieren außerdem von der Funktion GitLab Duo **Vulnerability\n    Resolution**, mit der automatisch ein Merge Request erstellt wird, der\n    Codeänderungen zur Behebung der Sicherheitslücke enthält. Diese KI-basierten\n    Funktionen tragen dazu bei, eine Anwendung sicherer zu machen und zu härten,\n    um Sicherheitslücken zu vermeiden, die in der Produktion dann Ziel von\n    Cyberangriffen werden könnten.\n\n\n    Neben SAST-Scannern bietet GitLab auch DAST-Scanner (dynamische\n    Anwendungssicherheitstest), für die eine laufende Anwendung erforderlich\n    ist. Wenn diese Scanner eingesetzt werden, kann GitLab automatisch eine\n    DAST-Umgebung für die DAST-Scans bereitstellen und dann nach dem DAST-Test\n    eine komplette Bereinigung aller Ressourcen durchführen. Zudem bietet GitLab\n    für ausgeführte Container das Operational Container Scanning (OCS) an, bei\n    dem Container-Images in deinem Cluster auf Sicherheitslücken überprüft\n    werden.\n\n\n    Die genannten Scans können automatisch in einer Merge-Request-Pipeline\n    ausgeführt werden. In einigen Fällen kann ihre Ausführung auch über\n    Scan-Ausführungs- oder Merge-Request-Approvalrichtlinien geplant werden.\n    Diese Richtlinien können über das GitLab-UI oder YAML-Dateien festgelegt\n    werden und werden in einem separaten Projekt konfiguriert. Dies ermöglicht\n    eine Aufgabentrennung, die die erneute Verwendung, die Wartung und die\n    Verwaltung vereinfacht. Scan-Ausführungsrichtlinien erfordern, dass\n    Sicherheitsscans nach einem bestimmten Zeitplan oder mit der Projektpipeline\n    ausgeführt werden, während Merge-Request-Approvalrichtlinien Maßnahmen auf\n    der Grundlage von Scan-Ergebnissen setzen. Security Engineers oder\n    Sicherheitsteams können diese Richtlinien festlegen, um Sicherheitsprozesse\n    im gesamten Unternehmen durchzusetzen. Da sich GitLab Flow durch alle\n    Schritte zieht, können diese Richtlinien vorkommen bzw. genutzt werden.Um\n    die Sicherheit und Compliance in deinem Unternehmen projektübergreifend\n    durchzusetzen, kannst du Compliance-Labels und -Pipelines verwenden. Du\n    kannst festlegen, dass Compliance-Labels und -Pipelines verpflichtend vor\n    der eigenen Pipeline eines Projekts ausgeführt werden müssen. Mit diesem\n    Ansatz kannst du sicherstellen, dass alle Teams in deinem Unternehmen deine\n    Sicherheits- und Compliance-Standards erfüllen. Darüber hinaus kannst du so\n    deine Anwendungen vor Cyberangriffen schützen, rechtlichen Vorgaben\n    entsprechen und stets für Audits bereit sein.\n\n\n    Das Hauptziel dieser Sicherheitsvorschriften von GitLab Flow ist,\n    Sicherheitslücken früh im Entwicklungsprozess zu beheben, ehe die Anwendung\n    in Produktion ist. Dann kann es nämlich sowohl teuer als auch schlecht für\n    den Ruf sein, eine solche Sicherheitslücke beheben zu müssen.\n\n\n    Wenn Sicherheitslücken in der inneren Feedbackschleife von GitLab Flow\n    behoben werden und weitere Updates an der Anwendung im Feature-Branch\n    vorgenommen werden, müssen die Beteiligten auch diese Updates erneut\n    überprüfen, um sicherzustellen, dass sie wirklich vorgenommen wurden und\n    dass keine versehentlichen Regressionen eingeführt wurden.\n\n\n    ### Kontinuierlicher Review\\\n\n\n    ![Reviews – das vierte Element von\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-reviewing-features-portion.png)\n\n    \u003Ccenter>Reviews – das vierte Element von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n\n    Das nächste Element von GitLab Flow ist der Review von Funktionen, also eine\n    kontinuierliche Überprüfung von Anwendungen. Die Review-Funktionen umfassen\n    die Möglichkeit, eine Review-Umgebung zu erstellen, in der die vorläufige\n    Anwendung (der sogenannte Feature-Branch) bereitgestellt wird, damit die\n    Beteiligten sie in Echtzeit überprüfen und ihr Feedback dazu abgeben können.\n    Die vorläufige Anwendung kann dann kontinuierlich angepasst werden, bis sie\n    mit dem Haupt-Branch zusammengeführt werden kann. GitLab Flow schreibt\n    außerdem eine Bereinigung aller in der Review-Umgebung bereitgestellten\n    Ressourcen zu dem Zeitpunkt vor, an dem der Merge Request mit dem\n    Haupt-Branch zusammengeführt wird.\n\n\n    Dieser iterative automatisierte Review-Prozess ist Teil der inneren\n    Feedbackschleife in GitLab Flow. Wie erwähnt ermöglichen in der inneren\n    Feedbackschleife GitLab-Duo-Funktionen wie Codeerläuterungen,\n    Codevorschläge, vorgeschlagene Prüfer(innen),\n    Merge-Request-Zusammenfassungen, Erstellung von Vorlagen für Merge Requests,\n    Code-Review-Zusammenfassungen, Erläuterungen von Sicherheitslücken, Behebung\n    von Sicherheitslücken und Grundursachenanalyse in GitLab Flow eine bessere\n    Übergabe zwischen Autor(inn)en und Prüfer(inne)n und optimieren den gesamten\n    Review-Prozess.\n\n\n    Die innere Feedbackschleife von GitLab Flow endet, wenn alle Review-Elemente\n    behandelt wurden, der Merge Request freigegeben wurde und mit dem\n    Haupt-Branch zusammengeführt wurde. Dies löst dann die Bereitstellung der\n    Anwendung für die Produktion aus.\n\n\n    ### Bereitstellung von Anwendungen und Infrastrukturen\n\n\n    ![Bereitstellen – das fünfte Element in\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The\\\n    -GitLab-Flow-2023-deploy-apps-portion.png)\n\n    \u003Ccenter>Bereitstellen – das fünfte Element in GitLab Flow]\u003C/center>\u003Cp>\u003C/p>\n\n\n    Abhängig von den Anforderungen eines Unternehmens gibt GitLab Flow entweder\n    kontinuierliche Lieferung oder kontinuierliche Bereitstellung vor. Während\n    man unter kontinuierlicher Lieferung die häufige Veröffentlichung von Code\n    durch manuelles Auslösen der Bereitstellungen (z. B. in die Produktion)\n    versteht, ist die kontinuierliche Bereitstellung die automatische\n    Veröffentlichung von Code (z. B. in die Produktion) ohne menschliches Zutun.\n    Sehen wir uns zunächst die kontinuierliche Lieferung an.\n\n\n    Wenn du deine Software mit kontinuierlicher Lieferung veröffentlichst, gibt\n    es verschiedene Bereitstellungsoptionen. Du kannst ein Standbild-Fenster\n    einrichten und dann mit fortschrittlichen Bereitstellungstechniken wie\n    Canary, Blue/Green, zeitlich abgestimmte und inkrementelle Rollouts\n    bereitstellen. Inkrementelle Rollouts können das Risiko von\n    Produktionsausfällen verringern, was zu einer besseren User Experience und\n    einer höheren Kundenzufriedenheit führt. Fortschrittliche\n    Bereitstellungstechniken können auch die Entwicklungs- und Liefereffizienz\n    verbessern und den Release-Prozess optimieren.\n\n\n    Wenn du deine Software mit kontinuierlicher Bereitstellung veröffentlichst,\n    gehen alle Änderungen/Updates direkt in die Produktion. Progressive\n    Bereitstellungsansätze wie Feature-Flags, mit denen du die Bereitstellung\n    bestimmter Funktionen von einer Markteinführung trennen kannst, sind eine\n    gute Möglichkeit, die Risiken zu reduzieren und zu verwalten, welche\n    Funktionen den Produktionsbenutzer(inne)n zur Verfügung gestellt werden\n    sollen. Feature-Flags unterstützen mehrere Programmiersprachen und\n    ermöglichen Experimente der Entwickler(innen) und kontrollierte Tests. Du\n    kannst sogar Feature-Flags verwenden, um Funktionen nur für bestimmte\n    Benutzer(innen) auszurollen.\n\n\n    GitLab unterstützt all diese Bereitstellungsansätze, doch GitLab Flow\n    ermöglicht nur die Umsetzung jenes Ansatzes, der am besten zum Unternehmen\n    und/oder zum spezifischen Projekt passt.\n\n\n    ### Überwachen von Anwendungen und DevSecOps-Prozessen\n\n    Sobald deine Anwendung für die Produktion bereitgestellt wurde, muss sie\n    kontinuierlich überwacht werden, um ihre Stabilität, Leistung und\n    Verfügbarkeit sicherzustellen. Darüber hinaus werden DevSecOps-Prozesse\n    gemessen, während sie ausgeführt werden, damit ihre Leistung und Effizienz\n    verbessert werden kann. Diese Überwachungsfunktionen werden von GitLab\n    bereitgestellt und können daher auch mit GitLab Flow genutzt werden.\n\n\n    GitLab bietet für ausgeführte Container das Operational Container Scanning\n    (OCS) an, bei dem Container-Images in deinem Cluster auf Sicherheitslücken\n    überprüft werden. Diese Scans können automatisiert werden, indem du planst,\n    wann sie ausgeführt werden. Gefundene Sicherheitslücken werden dann\n    automatisch in einem Sicherheitsdashboard angezeigt. Das OCS hilft dir\n    dabei, deine Cluster-Anwendungen zu schützen und Cyberangriffe, die zur\n    Veröffentlichung privater Daten und sogar zu unerwarteten Ausfällen führen\n    können, frühzeitig abzuwehren.\n\n\n    Die Fehlerverfolgung ermöglicht es Entwickler(inne)n, von ihrer Anwendung\n    generierte Fehler zu entdecken und anzuzeigen. Alle von deiner Anwendung\n    generierten Fehler werden in der Fehlerverfolgungsliste in GitLab angezeigt.\n    Die Fehlerverfolgung trägt zu einer besseren Verfügbarkeit und Leistung\n    deiner Anwendungen bei, indem unerwartete Anwendungsbedingungen schnell\n    erkannt und behoben werden.\n\n\n    GitLab kann über einen Webhook-Empfänger Alarme von beliebigen\n    Überwachungsquellen wie Prometheus erhalten. Wenn Alarme eingehen, werden\n    sie in der GitLab-Alarmliste angezeigt, von wo aus du sie dann manuell\n    verwalten kannst. Alarme können auch automatisch die Erstellung von\n    Vorfällen, ChatOps und E-Mails an die entsprechenden Personen oder Gruppen\n    auslösen. All diese Funktionen optimieren den Umgang mit Alarmen sowie deren\n    Bearbeitung.\n\n\n    Wenn Vorfälle aufgrund von Produktionsproblemen erstellt werden, werden sie\n    in der GitLab-Vorfall-Liste für das Vorfallmanagement angezeigt. Du kannst\n    einen oder mehrere Vorfälle verwalten, sie sortieren, durchsuchen, zuweisen,\n    ihren Status festlegen und sogar den vorab gesetzten SLA-Countdown-Timer\n    anzeigen. Darüber hinaus kannst du Bereitschaftspläne und -rotationen\n    erstellen, Eskalationsrichtlinien festlegen sowie Paging und\n    Benachrichtigungen für die Bearbeitung von Vorfällen einrichten. Außerdem\n    kannst du einen Vorfall mit einem Alarm verknüpfen. Wenn der Vorfall\n    geschlossen wird, wird der zugehörige Alarm automatisch als gelöst\n    gekennzeichnet. Vorfall-Zeitleisten sind eine weitere Funktion für\n    Führungskräfte und externe Betrachter(innen), um zu sehen, was während eines\n    Vorfalls passiert ist und welche Maßnahmen zur Behebung des Vorfalls\n    getroffen wurden. All diese Funktionen optimieren das Vorfallmanagement,\n    damit Vorfälle so schnell wie möglich gelöst werden können.\n\n\n    Audit Events verfolgen wichtige Ereignisse und zeichnen unter anderem auf,\n    wer die entsprechende Handlung zu welchem Zeitpunkt in GitLab ausgeführt\n    hat. Diese Ereignisse werden in der Audit-Event-Liste in GitLab angezeigt\n    und geben unter anderem Informationen zum Ereignis, das für ein Objekt\n    durchgeführt hatte, sowie die Person, die dieses Ereignis durchgeführt hat,\n    und Datum und Uhrzeit.\n\n\n    All diese Listen und Dashboards helfen, nicht konforme Szenarien und damit\n    zusammenhängende Strafen früh genug zu vermeiden sowie Audit-Prozesse zu\n    optimieren. Sie generieren Daten und Indikatoren für deine laufenden\n    Anwendungen, die dann in der äußeren Feedbackschleife von GitLab Flow\n    verwendet werden können, um deine Anwendungen zu verbessern und zu\n    optimieren und das Risiko unerwarteter Produktionsausfälle zu verringern.\n\n\n    ### Kontinuierliche Verbesserung\n\n    Wenn du GitLab Flow einsetzt, hast du auch die Möglichkeit, Einblicke mit\n    GitLab zu nutzen. Du erhältst diese in Form von durchgängigen\n    Prozessmetrik-Dashboards, damit du nicht nur deine Anwendungen, sondern auch\n    die Performance deiner Softwarebereitstellung kontinuierlich verbessern\n    kannst. Diese Dashboards und ihre Metriken werden von GitLab automatisch\n    generiert und sind immer verfügbar.\n\n\n    ### Dashboard für die Wertstromanalyse\n\n    Du kannst den Lebenszyklus deiner Anwendungsentwicklung über das Dashboard\n    für die Wertstromanalyse verfolgen und überwachen, denn hier kannst du\n    Projekt- und Gruppenstatistiken im Zeitverlauf anzeigen. Dieses Dashboard\n    ist anpassbar, du kannst aber auch gleich loslegen und eine\n    Wertschöpfungskette über eine der vorgefertigten Vorlagen von GitLab\n    erstellen. Das Standarddashboard zeigt Metriken für jede der vordefinierten\n    Phasen deiner Wertstromanalyse an, also Ticket, Planen, Programmieren,\n    Testen, Review und Staging. Außerdem wird ein Diagramm mit der\n    durchschnittlichen Zeit, die für den Abschluss der einzelnen Phasen benötigt\n    wird, angezeigt. Hier werden auch die wichtigsten Indikatoren der\n    Wertstromanalyse angezeigt: Abarbeitungsdauer, Bearbeitungszeit, neue\n    Tickets, Commits und Bereitstellungen. Du kannst anhand dieser Metriken\n    Verbesserungsbereiche in den einzelnen Phasen deiner Wertschöpfungskette\n    identifizieren.\n\n\n    ### DORA-Metrik-Dashboard\n\n    Um die Performance-Metriken anzuzeigen, die die Effektivität der Entwicklung\n    und der Bereitstellungspraktiken in deinem Unternehmen messen, gibt es in\n    GitLab das\n    [DORA-Metrik-Dashboard](https://about.gitlab.com/de-de/solutions/value-stre\\\n    am-management/dora/) (DevOps Research and Assessment), in dem vier wichtige\n    Metriken angezeigt werden: Häufigkeit der Bereitstellung, Vorlaufzeit für\n    Änderungen, Zeit bis zur Wiederherstellung des Service und\n    Änderungsfehlerrate. Die Häufigkeit der Bereitstellung misst, wie oft dein\n    Unternehmen Code in der Produktion bereitstellt oder für Endbenutzer(innen)\n    veröffentlicht. Die Vorlaufzeit für Änderungen misst, wie lange es vom\n    Commiten des Codes bis zur erfolgreichen Ausführung in der Produktion\n    dauert. Die Zeit bis zur Wiederherstellung des Service misst die Zeit, die\n    benötigt wird, um die Services bei einem Vorfall auf dem vorherigen Niveau\n    wiederherzustellen. Die letzte Kennzahl ist die Änderungsfehlerrate, also\n    der Prozentsatz an Änderungen an der Produktion bzw. an für Benutzer(innen)\n    veröffentlichten Anwendungen, die zu einem eingeschränkten Service führen\n    (z. B. durch eine Änderung, die zu einer Einschränkung des Service oder zu\n    einem Ausfall führte) und dementsprechende Behebung benötigen (in Form von\n    Hotfixes, Rollbacks oder Patches). Diese vier Schlüsselkennzahlen sind\n    Ergebnisse deine aktuellen Prozesse und geben dir die Möglichkeit, die\n    Faktoren und Funktionen zu verbessern, die dahinterstehen.\n\n\n    ### Anpassung deines Dashboards\n\n    Ein weiteres Dashboard ist das Wertstrom-Dashboard, ein anpassbares\n    Dashboard, mit dem Entscheidungsträger(innen) Trends, Muster und\n    Möglichkeiten für Verbesserungen im Bereich der Softwareentwicklung erkennen\n    können. Die gezeigten Metriken sind die DORA-Metriken, gefolgt von\n    Flow-Metriken für die Wertstromanalyse und Zähler für kritische und hohe\n    Sicherheitslücken im jeweiligen Monat bis zum aktuellen Datum, für die zwei\n    vorhergehenden Monate sowie die sechs vorhergehenden Monate.\n\n\n    GitLab Duo kann auch bei deinen Bestrebungen für kontinuierliche\n    Verbesserungen helfen. Die Funktion **Wertstromprognose** zieht historische\n    Daten heran und verwendet Datentrends aus deinem gesamten\n    Entwicklungslebenszyklus, um das zukünftige Verhalten deiner\n    Wertstrom-Metriken zu prognostizieren. Du kannst diese prädiktiven Analysen\n    für deine Optimierungen nutzen.\n\n\n    All diese Dashboards und die Indikatoren, die sie anzeigen, sind Teil der\n    äußeren Feedbackschleife von GitLab Flow. Sie helfen dir, das Risiko\n    ungeplanter Produktionsausfälle zu verringern sowie deine Anwendungen und\n    DevSecOps-Workflows zu verbessern.\n\n\n    ### KI-Impact-Analysen\n\n    Um die Auswirkungen von GitLab Duo (bzw. der KI) im gesamten\n    Entwicklungslebenszyklus besser zu verstehen, steht dir die\n    [KI-Impact-Analyse](https://about.gitlab.com/de-de/blog/developing-gitlab-d\\\n    uo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) zur Verfügung.\n    Hier siehst du, wie sich die Nutzung von Codevorschlägen von GitLab Duo auf\n    andere Leistungs-, Qualitäts- und Sicherheitsmetriken auswirkt. Du kannst\n    die letzten sechs Monate der KI-Einführung und ihre Auswirkungen auf andere\n    Indikatoren wie Bearbeitungszeit, Abarbeitungsdauer,\n    Bereitstellungshäufigkeit, Änderungsfehlerrate und kritische\n    Sicherheitslücken im Zeitverlauf visualisieren.\n\n\n    KI-Impact-Analysen helfen dir dabei, die Akzeptanz, Effektivität und\n    Vorteile zu messen, die die KI deinen Teams und deinem Unternehmen bringt.\n    Zudem tragen sie dazu bei, Verbesserungsbereiche zu identifizieren.\n\n\n    ## Warum solltest du GitLab Flow verwenden?\n\n    GitLab Flow ist ein vorgefertigter Ansatz, der von unseren Kund(inn)en und\n    Benutzer(inne)n auf der ganzen Welt eingesetzt wird und folgende Vorteile\n    bieten kann:\n\n\n    - Höhere Produktivität durch Automatisierungsmöglichkeiten von GitLab und\n    dessen vereinheitlichter Benutzeroberfläche und des einheitlichen\n    Datenmodells, die beide von GitLab Flow verwendet werden\n\n    - Genaue Einblicke in den gesamten DevSecOps-Lebenszyklus, um\n    kontinuierliche Verbesserungen zu ermöglichen\n\n    - Integrierte Dashboards und Metriken, die dir dabei helfen, deine\n    Anwendungen und DevSecOps-Prozesse zu optimieren\n\n    - Höhere Codequalität und verbesserte Zuverlässigkeit und Verfügbarkeit\n    deiner Anwendungen\n\n    - Bessere Anwendungssicherheit durch integrierte Sicherheitsscanner und\n    -funktionen\n\n    - Einhaltung von Compliance und Vorbereitung für Audits durch integrierte\n    Compliance-Funktionen\n\n    - Kürzere Bearbeitungszeiten für höhere Bereitstellungshäufigkeit\n\n    - Kontinuierliche Reviews durch die innere Feedbackschleife von GitLab Flow\n\n    - Die innere Feedbackschleife von GitLab Flow hilft dir, Anwendungs-Updates\n    zu optimieren, wodurch sich die Codequalität verbessert und deine\n    Anwendungen zuverlässiger und besser verfügbar werden\n\n    - Die äußere Feedbackschleife von GitLab Flow kann dazu beitragen, deine\n    Anwendungen sowie den Entwicklungslebenszyklus an sich zu verbessern\n\n    - Intensive Zusammenarbeit zwischen den Beteiligten in deinem Unternehmen\n\n    - Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den\n    Anwendungen zu finden,  bevor sie in die Produktion gelangen, wo solche\n    Fehler teure, ungeplante Ausfälle verursachen können\\\n\n    - Niedrigeres Risiko bei der Bereitstellung in die Produktion durch\n    fortschrittliche Bereitstellungstechnicken und den progressiven Lieferansatz\n    von GitLab\n\n    - KI-Funktionen im gesamten Entwicklungslebenszyklus können Produktivität,\n    Codequalität, kontinuierliche Verbesserung, Sicherheit, Compliance und mehr\n    verbessern\n\n    - Unterstützung für Cloud-native und nicht-Cloud-native Anwendungen\n\n    - Multi-Cloud-Support für hybride Anwendungen und Multi-Cloud-Anwendungen\n\n    - Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den\n    Anwendungen zu finden, bevor sie in die Produktion gelangen, wo solche\n    Fehler teure, ungeplante Ausfälle verursachen können\n\n\n    Wie kannst du mit GitLab Flow durchstarten? Ein guter Ausgangspunkt, um die\n    Prinzipien von GitLab Flow für deinen Lebenszyklus der Anwendungsentwicklung\n    einzuführen, sind Auto-DevOps von GitLab.\n\n\n    ## GitLab Flow und Auto-DevOps\n\n\n    ![Auto DevOps – eine Instanziierung von\n    GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/ado\\\n    -pipeline.png)\n\n    \u003Ccenter>Auto-DevOps – eine Instanziierung von GitLab Flow\u003C/center>\u003Cp>\u003C/p>Bei\n    [Auto-DevOps](https://docs.gitlab.com/topics/autodevops/) wird\n    GitLab Flow in allen Phasen und Jobs angewendet. Du kannst es dir als ein\n    gutes Beispiel für die Instanziierung von GitLab Flow vorstellen.\n\n\n    Auto-DevOps ist eine Sammlung vordefinierter, sofort einsatzbereiter\n    CI/CD-Vorlagen, die deinen Quellcode automatisch erkennen. Basierend auf\n    bewährten Methoden können diese Vorlagen deine Anwendungen automatisch\n    erkennen, erstellen, testen, bereitstellen und überwachen.\n\n\n    Die Auto-DevOps-Pipeline kontrolliert die Sicherheit im Vorfeld, um Fehler\n    so früh wie möglich im Softwarelieferprozess zu finden und zu vermeiden. Die\n    Pipeline stellt die Anwendung dann zur Verifizierung im Staging und dann\n    inkrementell/zeitgesteuert in der Produktion bereit.\n\n\n    Mit Auto-DevOps kannst du rasch durchstarten, die Produktivität der\n    Entwickler(innen) steigern und das Ganze einfach an deine Bedürfnisse\n    anpassen. Außerdem erhältst du Unterstützung für die bekanntesten\n    Programmier-Frameworks und -sprachen. Auto-DevOps ist modular, anpassbar und\n    erweiterbar, sodass du sowohl nur einzelne Elemente in deiner Pipeline\n    nutzen oder das Gesamtpaket für deine Anwendung einsetzen kannst.\n\n\n    ## Los geht’s\n\n    [Kombiniere jetzt GitLab Flow und\n    GitLab Duo](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&\\\n    glm_source=about.gitlab.com%2Fblog%2F), um die Effizienz deiner Workflows\n    von Anfang bis Ende deutlich zu verbessern. So kannst du eine noch höhere\n    Produktivität, Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie\n    verbesserte Resilienz und Verfügbarkeit deiner Produktion erreichen.\n\n\n    Wenn du sehen möchtest, wie ein Workflow funktioniert, der GitLab Flow und\n    GitLab Duo kombiniert und wie du davon profitieren kannst, schau dir das\n    folgende Video an:\n\n\n    \u003C!-- blank line -->\n\n    \u003Cfigure class=\\\"video_container\\\">\n\n    \\  \u003Ciframe\n    src=\\\"https://www.youtube.com/embed/CKrZ4_tKY4I?si=Kf6QsYFIzKkJZpJd\\\"\n    frameborder=\\\"0\\\" allowfullscreen=\\\"true\\\"> \u003C/iframe>\n\n    \u003C/figure>\n\n    \u003C!-- blank line -->\\n\"\n  category: ai-ml\n  tags:\n    - CI/CD\n    - AI/ML\n    - DevSecOps\n  updatedDate: '2025-04-21'\nconfig:\n  slug: gitlab-flow-duo\n  featured: false\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":14,"ogImage":19,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/gitlab-flow-duo","https://about.gitlab.com","article","de-de/blog/gitlab-flow-duo",[38,39,40],"cicd","aiml","devsecops",[22,23,24],"u0YflfeQSUwOu561biiVIh_huPNJo5LBcCMHKj0SNuA",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":374,"minimal":408,"duo":426,"switchNav":435,"pricingDeployment":446},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/de-de/","gitlab logo","header",{"text":51,"config":52},"Kostenlose Testversion anfordern",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Vertrieb kontaktieren",{"href":58,"dataGaName":59,"dataGaLocation":49},"/de-de/sales/","sales",{"text":61,"config":62},"Anmelden",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,189,194,295,355],{"text":67,"config":68,"cards":70},"Plattform",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":74,"config":75},"Die Plattform erkunden",{"href":76,"dataGaName":69,"dataGaLocation":49},"/de-de/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":81,"config":82},"Lerne GitLab Duo kennen",{"href":83,"dataGaName":84,"dataGaLocation":49},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":89,"config":90},"Mehr erfahren",{"href":91,"dataGaName":92,"dataGaLocation":49},"/de-de/why-gitlab/","why gitlab",{"text":94,"left":29,"config":95,"link":97,"lists":101,"footer":171},"Produkt",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"Alle Lösungen anzeigen",{"href":100,"dataGaName":96,"dataGaLocation":49},"/de-de/solutions/",[102,126,149],{"title":103,"description":104,"link":105,"items":110},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[111,114,117,122],{"text":22,"config":112},{"href":113,"dataGaLocation":49,"dataGaName":22},"/de-de/solutions/continuous-integration/",{"text":78,"config":115},{"href":83,"dataGaLocation":49,"dataGaName":116},"gitlab duo agent platform - product menu",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":49,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatische Softwarebereitstellung",{"href":108,"dataGaLocation":49,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":49,"icon":133},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Anwendungssicherheitstests",{"href":131,"dataGaName":138,"dataGaLocation":49},"Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":49,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software-Compliance",{"href":147,"dataGaName":148,"dataGaLocation":49},"/de-de/solutions/software-compliance/","software compliance",{"title":150,"link":151,"items":156},"Auswertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":49},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Auswertung",{"href":154,"dataGaLocation":49,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":49,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":49,"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":49,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":49,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"Öffentlicher Sektor",{"href":187,"dataGaLocation":49,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":49,"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":49},"/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":49},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":49},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":49,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":49},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":49},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":49},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":49},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":49},"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":49},"/de-de/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":49},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Veranstaltungen",{"href":275,"dataGaName":276,"dataGaLocation":49},"/events/","events",{"text":278,"config":279},"Partner",{"href":280,"dataGaName":281,"dataGaLocation":49},"/de-de/partners/","partners",{"background":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-Karte",{"src":289},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":291,"config":292},"Aktuelles",{"href":293,"dataGaName":294,"dataGaLocation":49},"/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":49},"/de-de/company/","about",{"text":308,"config":309,"footerGa":312},"Karriere",{"href":310,"dataGaName":311,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":49},{"text":316,"config":317},"Geschäftsführung",{"href":318,"dataGaName":319,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":49},"/company/team/","team",{"text":326,"config":327},"Handbuch",{"href":328,"dataGaName":329,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor Relations",{"href":333,"dataGaName":334,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":49},"/de-de/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":49},"/de-de/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":351,"config":352},"Presse",{"href":353,"dataGaName":354,"dataGaLocation":49},"/press/","press",{"text":356,"config":357,"lists":358},"Kontakt",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":56,"config":362},{"href":58,"dataGaName":363,"dataGaLocation":49},"talk to sales",{"text":365,"config":366},"Support-Portal",{"href":367,"dataGaName":368,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":370,"config":371},"Kundenportal",{"href":372,"dataGaName":373,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Schließen",{"text":377,"link":378},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":379,"config":380},"gitlab.com",{"href":63,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Vorschläge",[386,388,393,395,400,405],{"text":78,"config":387},{"href":83,"dataGaName":78,"dataGaLocation":382},{"text":389,"config":390},"Codevorschläge (KI)",{"href":391,"dataGaName":392,"dataGaLocation":382},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":22,"config":394},{"href":113,"dataGaName":22,"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":86,"config":406},{"href":91,"dataGaName":407,"dataGaLocation":382},"Why GitLab?",{"freeTrial":409,"mobileIcon":414,"desktopIcon":419,"secondaryButton":422},{"text":410,"config":411},"Kostenlos testen",{"href":412,"dataGaName":54,"dataGaLocation":413},"https://gitlab.com/-/trials/new/","nav",{"altText":415,"config":416},"GitLab-Symbol",{"src":417,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":415,"config":420},{"src":421,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":204,"config":423},{"href":424,"dataGaName":425,"dataGaLocation":413},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"Mehr über GitLab Duo erfahren",{"href":83,"dataGaName":430,"dataGaLocation":413},"gitlab duo",{"altText":415,"config":432},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":434},{"src":421,"dataGaName":418,"dataGaLocation":413},{"button":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"/Option",{"href":439,"dataGaName":440,"dataGaLocation":413},"#contact","switch",{"altText":415,"config":442},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":444},{"src":445,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":447,"mobileIcon":452,"desktopIcon":454},{"text":448,"config":449},"Zurück zur Preisübersicht",{"href":192,"dataGaName":450,"dataGaLocation":413,"icon":451},"back to pricing","GoBack",{"altText":415,"config":453},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":455},{"src":421,"dataGaName":418,"dataGaLocation":413},{"title":457,"button":458,"config":463},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":459,"config":460},"GitLab Transcend jetzt ansehen",{"href":461,"dataGaName":462,"dataGaLocation":49},"/de-de/events/transcend/virtual/","transcend event",{"layout":464,"icon":465,"disabled":29},"release","AiStar",{"data":467},{"text":468,"source":469,"edit":475,"contribute":480,"config":485,"items":490,"minimal":690},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":470,"config":471},"Quelltext der Seite anzeigen",{"href":472,"dataGaName":473,"dataGaLocation":474},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":476,"config":477},"Diese Seite bearbeiten",{"href":478,"dataGaName":479,"dataGaLocation":474},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":481,"config":482},"Beteilige dich",{"href":483,"dataGaName":484,"dataGaLocation":474},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":486,"facebook":487,"youtube":488,"linkedin":489},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[491,536,586,628,655],{"title":190,"links":492,"subMenu":507},[493,497,502],{"text":494,"config":495},"Tarife anzeigen",{"href":192,"dataGaName":496,"dataGaLocation":474},"view plans",{"text":498,"config":499},"Vorteile von Premium",{"href":500,"dataGaName":501,"dataGaLocation":474},"/de-de/pricing/premium/","why premium",{"text":503,"config":504},"Vorteile von Ultimate",{"href":505,"dataGaName":506,"dataGaLocation":474},"/de-de/pricing/ultimate/","why ultimate",[508],{"title":356,"links":509},[510,512,514,516,521,526,531],{"text":56,"config":511},{"href":58,"dataGaName":59,"dataGaLocation":474},{"text":365,"config":513},{"href":367,"dataGaName":368,"dataGaLocation":474},{"text":370,"config":515},{"href":372,"dataGaName":373,"dataGaLocation":474},{"text":517,"config":518},"Status",{"href":519,"dataGaName":520,"dataGaLocation":474},"https://status.gitlab.com/","status",{"text":522,"config":523},"Nutzungsbedingungen",{"href":524,"dataGaName":525,"dataGaLocation":474},"/terms/","terms of use",{"text":527,"config":528},"Datenschutzerklärung",{"href":529,"dataGaName":530,"dataGaLocation":474},"/de-de/privacy/","privacy statement",{"text":532,"config":533},"Cookie-Einstellungen",{"dataGaName":534,"dataGaLocation":474,"id":535,"isOneTrustButton":29},"cookie preferences","ot-sdk-btn",{"title":94,"links":537,"subMenu":546},[538,542],{"text":539,"config":540},"DevSecOps-Plattform",{"href":76,"dataGaName":541,"dataGaLocation":474},"devsecops platform",{"text":543,"config":544},"KI-unterstützte Entwicklung",{"href":83,"dataGaName":545,"dataGaLocation":474},"ai-assisted development",[547],{"title":548,"links":549},"Themen",[550,553,558,563,568,571,576,581],{"text":22,"config":551},{"href":552,"dataGaName":38,"dataGaLocation":474},"/de-de/topics/ci-cd/",{"text":554,"config":555},"GitOps",{"href":556,"dataGaName":557,"dataGaLocation":474},"/de-de/topics/gitops/","gitops",{"text":559,"config":560},"DevOps",{"href":561,"dataGaName":562,"dataGaLocation":474},"/de-de/topics/devops/","devops",{"text":564,"config":565},"Versionskontrolle",{"href":566,"dataGaName":567,"dataGaLocation":474},"/de-de/topics/version-control/","version control",{"text":24,"config":569},{"href":570,"dataGaName":40,"dataGaLocation":474},"/de-de/topics/devsecops/",{"text":572,"config":573},"Cloud-nativ",{"href":574,"dataGaName":575,"dataGaLocation":474},"/de-de/topics/cloud-native/","cloud native",{"text":577,"config":578},"KI für das Programmieren",{"href":579,"dataGaName":580,"dataGaLocation":474},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":582,"config":583},"Agentische KI",{"href":584,"dataGaName":585,"dataGaLocation":474},"/de-de/topics/agentic-ai/","agentic ai",{"title":587,"links":588},"Lösungen",[589,592,594,599,603,606,609,612,614,616,618,623],{"text":136,"config":590},{"href":131,"dataGaName":591,"dataGaLocation":474},"Application Security Testing",{"text":123,"config":593},{"href":108,"dataGaName":109,"dataGaLocation":474},{"text":595,"config":596},"Agile Entwicklung",{"href":597,"dataGaName":598,"dataGaLocation":474},"/de-de/solutions/agile-delivery/","agile delivery",{"text":600,"config":601},"SCM",{"href":120,"dataGaName":602,"dataGaLocation":474},"source code management",{"text":22,"config":604},{"href":113,"dataGaName":605,"dataGaLocation":474},"continuous integration & delivery",{"text":162,"config":607},{"href":164,"dataGaName":608,"dataGaLocation":474},"value stream management",{"text":554,"config":610},{"href":611,"dataGaName":557,"dataGaLocation":474},"/de-de/solutions/gitops/",{"text":175,"config":613},{"href":177,"dataGaName":178,"dataGaLocation":474},{"text":180,"config":615},{"href":182,"dataGaName":183,"dataGaLocation":474},{"text":185,"config":617},{"href":187,"dataGaName":188,"dataGaLocation":474},{"text":619,"config":620},"Bildungswesen",{"href":621,"dataGaName":622,"dataGaLocation":474},"/de-de/solutions/education/","education",{"text":624,"config":625},"Finanzdienstleistungen",{"href":626,"dataGaName":627,"dataGaLocation":474},"/de-de/solutions/finance/","financial services",{"title":195,"links":629},[630,632,634,636,639,641,643,645,647,649,651,653],{"text":207,"config":631},{"href":209,"dataGaName":210,"dataGaLocation":474},{"text":212,"config":633},{"href":214,"dataGaName":215,"dataGaLocation":474},{"text":217,"config":635},{"href":219,"dataGaName":220,"dataGaLocation":474},{"text":222,"config":637},{"href":224,"dataGaName":638,"dataGaLocation":474},"docs",{"text":245,"config":640},{"href":247,"dataGaName":248,"dataGaLocation":474},{"text":240,"config":642},{"href":242,"dataGaName":243,"dataGaLocation":474},{"text":250,"config":644},{"href":252,"dataGaName":253,"dataGaLocation":474},{"text":258,"config":646},{"href":260,"dataGaName":261,"dataGaLocation":474},{"text":263,"config":648},{"href":265,"dataGaName":266,"dataGaLocation":474},{"text":268,"config":650},{"href":270,"dataGaName":271,"dataGaLocation":474},{"text":273,"config":652},{"href":275,"dataGaName":276,"dataGaLocation":474},{"text":278,"config":654},{"href":280,"dataGaName":281,"dataGaLocation":474},{"title":296,"links":656},[657,659,661,663,665,667,669,674,679,681,683,685],{"text":303,"config":658},{"href":305,"dataGaName":298,"dataGaLocation":474},{"text":308,"config":660},{"href":310,"dataGaName":311,"dataGaLocation":474},{"text":316,"config":662},{"href":318,"dataGaName":319,"dataGaLocation":474},{"text":321,"config":664},{"href":323,"dataGaName":324,"dataGaLocation":474},{"text":326,"config":666},{"href":328,"dataGaName":329,"dataGaLocation":474},{"text":331,"config":668},{"href":333,"dataGaName":334,"dataGaLocation":474},{"text":670,"config":671},"Nachhaltigkeit",{"href":672,"dataGaName":673,"dataGaLocation":474},"/sustainability/","Sustainability",{"text":675,"config":676},"Vielfalt, Inklusion und Zugehörigkeit",{"href":677,"dataGaName":678,"dataGaLocation":474},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":680},{"href":338,"dataGaName":339,"dataGaLocation":474},{"text":346,"config":682},{"href":348,"dataGaName":349,"dataGaLocation":474},{"text":351,"config":684},{"href":353,"dataGaName":354,"dataGaLocation":474},{"text":686,"config":687},"Transparenzerklärung zu moderner Sklaverei",{"href":688,"dataGaName":689,"dataGaLocation":474},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,694,697],{"text":522,"config":693},{"href":524,"dataGaName":525,"dataGaLocation":474},{"text":695,"config":696},"Cookies",{"dataGaName":534,"dataGaLocation":474,"id":535,"isOneTrustButton":29},{"text":527,"config":698},{"href":529,"dataGaName":530,"dataGaLocation":474},[700],{"id":701,"title":9,"body":27,"config":702,"content":704,"description":27,"extension":26,"meta":708,"navigation":29,"path":709,"seo":710,"stem":711,"__hash__":712},"blogAuthors/en-us/blog/authors/cesar-saavedra.yml",{"template":703},"BlogAuthor",{"name":9,"config":705},{"headshot":706,"ctfId":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659600/Blog/Author%20Headshots/csaavedra1-headshot.jpg","csaavedra1",{},"/en-us/blog/authors/cesar-saavedra",{},"en-us/blog/authors/cesar-saavedra","SMqRf-z0W5m5GROz_dXGjmuIb3YaOwm_n_RfeK16GcA",[714,727,740],{"content":715,"config":725},{"title":716,"description":717,"authors":718,"heroImage":720,"date":721,"body":722,"category":11,"tags":723},"GitLab und Anthropic: Governed AI für die Unternehmensentwicklung","GitLab vertieft die Anthropic-Integration – KI-Governance, Auditierbarkeit und Cloud-Flexibilität für regulierte Unternehmen und den öffentlichen Sektor.",[719],"Stuart Moncada","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","2026-04-28","Für Führungskräfte in Unternehmen und im öffentlichen Sektor ist die Spannung\nvertraut: Softwareteams müssen mit KI schneller werden, während Sicherheits-,\nCompliance- und regulatorische Anforderungen weiter steigen. GitLab vertieft\ndie Integration mit Anthropic Claude, sodass Unternehmen Zugang zu neu\nveröffentlichten Claude-Modellen innerhalb von GitLabs intelligenter\nOrchestrierungsplattform erhalten – dort, wo Governance, Compliance und\nAuditierbarkeit bereits verankert sind.\n\nClaude treibt Funktionen der gesamten GitLab Duo Agent Platform als\nStandardmodell an – für Anwendungsfälle von Code-Generierung und -Review bis\nhin zu agentischem Chat und Vulnerability Resolution. Wer GitLab Duo bereits\nnutzt, hat bereits erlebt, wie Duo-Agenten Workflows über den gesamten Software\nDevelopment Lifecycle (SDLC) automatisieren.\n\nDas beschleunigt die Integration von Claudes Fähigkeiten in GitLab, erweitert\ndie Deployment-Optionen für Unternehmen und unterstreicht, was GitLab als\nPlattform für Softwareentwicklung grundlegend unterscheidet: Governance,\nCompliance und Auditierbarkeit, die in jede KI-Interaktion eingebaut sind.\n\n> \"GitLab Duo hat beschleunigt, wie unsere Teams Software planen, bauen und\n> ausliefern. Die Kombination aus Anthropics Claude und GitLabs Plattform\n> bedeutet, dass wir leistungsfähigere KI erhalten, ohne zu ändern, wie wir\n> arbeiten oder wie sie kontrolliert wird.\"\n>\n> – Mans Booijink, Operations Manager, Cube\n\n\n## Der entscheidende Unterschied: Governed AI\n\nBei GitLab sind Governance-Kontrollen und Auditing in den SDLC eingebaut. Wenn\nClaude über die GitLab Duo Agent Platform eine Codeänderung vorschlägt, durchläuft\ndieser Vorschlag denselben Merge-Request-Prozess, dieselben Freigaberegeln,\ndasselbe Security Scanning und denselben Audit-Trail wie jede andere Änderung.\nKI erhält keine Ausnahme von den bestehenden Kontrollen. Sie operiert innerhalb\ndieser Kontrollen.\n\nJe weiter GitLab in die agentische Softwareentwicklung vordringt – bei der KI\nklar definierte Aufgaben autonom übernimmt – desto wichtiger wird die\nGovernance-Schicht. Ein KI-Agent, der einen Merge Request öffnen, eine\nSchwachstelle beheben oder einen Service refaktorieren kann, muss auditierbar\nund zuordenbar sein und denselben Richtliniendurchsetzungen unterliegen wie ein\nmenschlicher Entwickler. Diese Anforderung ist eine architektonische Entscheidung,\ndie GitLab von Beginn an getroffen hat – und die umso bedeutsamer wird, je mehr\nVerantwortung KI-Agenten übernehmen.\n\n\n## Deployment-Flexibilität für Unternehmen\n\nDie Integration erweitert auch, wie Unternehmen über GitLab auf die neuesten\nClaude-Modelle zugreifen. Claude ist innerhalb von GitLab über Google Cloud\nVertex AI und AWS Bedrock verfügbar – Unternehmen können KI-Workloads über die\nHyperscaler-Commitments und Cloud-Governance-Frameworks leiten, die bereits\nbestehen. Kein separater Anbietervertrag, keine neuen Fragen zur Datenresidenz.\nDie bestehende GCP- oder AWS-Beziehung ist der Einstiegspunkt.\n\nGitLab ist jetzt auch im [Claude Marketplace](https://claude.com/platform/marketplace)\nverfügbar. Kunden können dort GitLab Credits erwerben und auf bestehende\nAnthropic-Ausgaben-Commitments anrechnen – KI-Ausgaben konsolidieren und die\nBeschaffung von GitLab neben Anthropic-Investitionen vereinfachen.\n\n\n## Auf dem Weg in eine agentische Zukunft\n\nGitLabs Vision für agentische Softwareentwicklung – bei der KI definierte\nAufgaben autonom über Planung, Coding, Testing, Security und Deployment hinweg\nübernimmt – setzt Modelle mit starkem Reasoning, Zuverlässigkeit und\nSicherheitseigenschaften voraus. Und sie setzt eine Plattform voraus, auf der\ndiese autonomen Aktionen vollständig kontrolliert werden.\n\nAgentische Workflows erfordern Modelle mit starkem Reasoning, Zuverlässigkeit\nund Sicherheitseigenschaften – Kriterien, die die Auswahl und Integration von\nKI-Modellpartnern bei GitLab leiten. GitLabs Governance-Framework stellt sicher,\ndass Unternehmen bei zunehmendem KI-Einsatz in der Entwicklung vollständige\nTransparenz und Kontrolle darüber behalten, was diese Agenten tun, wann sie es\ntun und wie Änderungen nachverfolgt werden.\n\n\n## Was das für GitLab-Kunden bedeutet\n\nWer GitLab Duo Agent Platform bereits einsetzt, erhält Zugang zu Claude-Modellen\nund tieferer KI-Unterstützung über den gesamten Software Development Lifecycle –\ninnerhalb des Governance-Frameworks, auf das bereits vertraut wird.\n\nWer KI-gestützte Softwareentwicklungsplattformen evaluiert, sollte nicht zwischen\nfortschrittlichen KI-Fähigkeiten und Unternehmenskontrolle wählen müssen. Diese\nstrategische Integration ist darauf ausgelegt, beides zu liefern.\n\n> Mehr über GitLab Duo Agent Platform erfahren?\n> [Demo anfragen oder kostenlose Testversion starten](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/).\n",[23,724,281],"product",{"featured":29,"template":15,"slug":726},"gitlab-and-anthropic-governed-ai-for-enterprise-development",{"content":728,"config":738},{"title":729,"description":730,"authors":731,"heroImage":733,"date":734,"body":735,"category":11,"tags":736},"glab CLI: Strukturierter GitLab-Zugriff für KI-Agenten","Das GitLab CLI (glab) gibt KI-Agenten strukturierten Zugriff auf Projekte via MCP. Tutorial: Code-Reviews und Issue-Triage mit glab beschleunigen.",[732],"Kai Armstrong","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776347152/unw3mzatkd5xyfbzcnni.png","2026-04-27","Wenn Teams GitLab Duo, Claude, Cursor und andere KI-Assistenten einsetzen,\nläuft ein wachsender Teil des Entwicklungs-Workflows über einen KI-Agenten,\nder im eigenen Auftrag handelt – Issues liest, Merge Requests prüft, Pipelines\nausführt und dabei hilft, schneller zu liefern. Die meisten Entwickler(innen) nutzen\n`glab` bereits vom Terminal aus, um mit GitLab zu interagieren. Beides zu\nkombinieren ist der naheliegende nächste Schritt.\n\nDas Problem: Ohne die richtigen Werkzeuge rät ein KI-Agent im Wesentlichen,\nwenn es um GitLab-Projekte geht. Er könnte die Details eines Issues\nhalluzinieren, den er nie gesehen hat, einen Merge Request auf Basis veralteter\nTrainingsdaten zusammenfassen statt anhand seines tatsächlichen Zustands – oder\nverlangen, dass Kontext manuell aus einem Browser-Tab kopiert und in ein\nChat-Fenster eingefügt wird, bevor überhaupt begonnen werden kann. Jede dieser\nUmgehungslösungen ist Reibung: Sie verlangsamt die Arbeit, eröffnet\nFehlermöglichkeiten und setzt eine harte Obergrenze dafür, was der Agent\ntatsächlich leisten kann. Das GitLab CLI (`glab`) ändert das, indem es Agenten\neine direkte, zuverlässige Schnittstelle zu Projekten gibt.\n\nMit `glab` ruft der Agent das Benötigte direkt von GitLab ab, handelt darauf\nund meldet das Ergebnis zurück – sodass weniger Zeit damit verbracht wird,\nInformationen weiterzugeben, und mehr Zeit für die eigentliche Arbeit bleibt.\n\nIn diesem Tutorial wird gezeigt, wie `glab` KI-Agenten strukturierten,\nzuverlässigen Zugriff auf GitLab-Projekte ermöglicht – und wie das einen\nschnelleren, leistungsfähigeren Entwicklungs-Workflow freischaltet.\n\n\n## KI-Agent über MCP mit GitLab verbinden\n\nDer direkteste Weg, KI-Workflows deutlich leistungsfähiger zu machen, besteht\ndarin, dem KI-Agenten nativen Zugriff auf `glab` über das Model Context\nProtocol ([MCP](https://about.gitlab.com/topics/ai/model-context-protocol/))\nzu geben.\n\nMCP ist ein offener Standard, der KI-Werkzeugen ermöglicht, externe Fähigkeiten\nzur Laufzeit zu entdecken und zu nutzen. Nach der Verbindung kann der\nKI-Assistent Issues lesen, Merge Requests kommentieren, Pipeline-Status prüfen\nund zurück in GitLab schreiben – ohne etwas aus der UI zu kopieren oder auch\nnur einen einzigen API-Aufruf selbst zu schreiben.\n\nEinstieg mit:\n\n```shell\n# MCP-Server von glab starten\nglab mcp serve\n```\n\nSobald der MCP-Client konfiguriert ist, kann die KI Fragen wie *„Was ist der\nStatus meiner offenen MRs?\"* oder *„Gibt es fehlgeschlagene Pipelines auf\nmain?\"* beantworten, indem sie GitLab direkt abfragt – nicht durch Scraping der\nWeb-UI, nicht durch veraltete Trainingsdaten. Die\n[vollständige Setup-Dokumentation](https://docs.gitlab.com/cli/) enthält\nKonfigurationsschritte für Claude Code, Cursor und andere Editoren.\n\nEin wichtiges Detail: `glab` fügt automatisch `--output json` hinzu, wenn es\nüber MCP aufgerufen wird – für jeden Befehl, der das unterstützt. Der Agent\nerhält saubere, strukturierte Daten, ohne dass über Ausgabeformate nachgedacht\nwerden muss. Und da `glab` das offizielle MCP SDK verwendet, bleibt es\nkompatibel, wenn sich das Protokoll weiterentwickelt.\n\nWir haben bewusst entschieden, *welche* Befehle über MCP zugänglich sind.\nBefehle, die interaktive Terminalausgabe erfordern, sind absichtlich\nausgeschlossen – der Agent bleibt nie in einem Wartezustand für Eingaben, die\nnie kommen. Was zugänglich ist, funktioniert zuverlässig im Agenten-Kontext.\n\n\n## KI am Code-Review beteiligen\n\nDie meisten Entwickler(innen) haben einen Rückstand an MRs, die auf Review warten.\nDas ist einer der zeitintensivsten Teile der Arbeit – und einer der besten\nAnsatzpunkte für KI. Mit `glab` beobachtet der Agent die Review-Queue nicht\nnur, sondern arbeitet sie gemeinsam durch.\n\n### Genau sehen, was noch offen ist\n\nEinstieg mit:\n\n```shell\nglab mr view 2677 --comments --unresolved --output json\n```\n\nDieser Befehl gibt den vollständigen MR zurück: Metadaten, Beschreibung und\njede ungelöste Diskussion als einzelnes strukturiertes JSON-Payload. Das gibt\nder KI alles, was sie braucht: welche Threads offen sind, was der Reviewer\nangefragt hat und in welchem Kontext. Kein Tab-Wechsel, kein manuelles Kopieren\neinzelner Kommentare.\n\n```json\n{\n  \"id\": 2677,\n  \"title\": \"feat: add OAuth2 support\",\n  \"state\": \"opened\",\n  \"author\": { \"username\": \"jdwick\" },\n  \"labels\": [\"backend\", \"needs-review\"],\n  \"blocking_discussions_resolved\": false,\n  \"discussions\": [\n    {\n      \"id\": \"3107030349\",\n      \"resolved\": false,\n      \"notes\": [\n        {\n          \"author\": { \"username\": \"dmurphy\" },\n          \"body\": \"This error handling will swallow panics — consider wrapping with recover()\",\n          \"created_at\": \"2026-03-14T09:23:11.000Z\"\n        }\n      ]\n    },\n    {\n      \"id\": \"3107030412\",\n      \"resolved\": false,\n      \"notes\": [\n        {\n          \"author\": { \"username\": \"sreeves\" },\n          \"body\": \"Token refresh logic needs a test for the expired token case\",\n          \"created_at\": \"2026-03-14T10:05:44.000Z\"\n        }\n      ]\n    }\n  ]\n}\n```\n\nStatt jeden Thread selbst durchzulesen, lässt sich der Agent fragen:\n*„Was muss ich in MR 2677 noch beheben?\"* – und erhält eine priorisierte\nZusammenfassung mit Änderungsvorschlägen. Das alles aus einem einzigen Befehl.\n\n### Den Kreislauf programmatisch schließen\n\nSobald der KI geholfen hat, das Feedback zu adressieren, kann sie Diskussionen\nauflösen:\n\n```shell\n# Alle Diskussionen auflisten – strukturiert, bereit für den Agenten\nglab mr note list 456 --output json\n\n# Diskussion auflösen, sobald das Feedback adressiert wurde\nglab mr note resolve 456 3107030349\n\n# Wieder öffnen, wenn etwas erneut geprüft werden muss\nglab mr note reopen 456 3107030349\n```\n\n```json\n[\n  {\n    \"id\": 3107030349,\n    \"body\": \"This error handling will swallow panics — consider wrapping with recover()\",\n    \"author\": { \"username\": \"dmurphy\" },\n    \"resolved\": false,\n    \"resolvable\": true\n  },\n  {\n    \"id\": 3107030412,\n    \"body\": \"Token refresh logic needs a test for the expired token case\",\n    \"author\": { \"username\": \"sreeves\" },\n    \"resolved\": false,\n    \"resolvable\": true\n  }\n]\n```\n\nNote-IDs sind direkt in der GitLab-UI und der API sichtbar – kein zusätzlicher\nLookup nötig. Der Agent kann die vollständige Liste durcharbeiten, jeden Fix\nprüfen und dabei auflösen.\n\n\n## Mit der KI effektiver über Code sprechen\n\nAuch ohne laufenden MCP-Server gibt es eine einfachere Umstellung, die einen\ngroßen Unterschied macht: `glab` einsetzen, um der KI bessere Informationen zu\nliefern.\n\nBeim letzten Mal, als ein KI-Assistent bei der Issue-Triage oder beim Debuggen\neiner fehlgeschlagenen Pipeline geholfen hat, wurde wahrscheinlich etwas Text\naus der GitLab-UI kopiert und in den Chat eingefügt. Das ist es, womit der\nAgent tatsächlich arbeitet:\n\n```text\nopen issues: 12 • milestone: 17.10 • label: bug, needs-triage ...\n```\n\nIm Vergleich dazu, was er mit `glab` erhält:\n\n```json\n[\n  {\n    \"iid\": 902,\n    \"title\": \"Pipeline fails on merge to main\",\n    \"labels\": [\"bug\", \"needs-triage\"],\n    \"milestone\": { \"title\": \"17.10\" },\n    \"assignees\": []\n  },\n  ...\n]\n```\n\nStrukturiert, typisiert, vollständig – keine Mehrdeutigkeit, kein\nInterpretationsaufwand beim Parsen. Das ist der Unterschied zwischen einem\nAgenten, der handeln kann, und einem, der Rückfragen stellen muss.\n\nMit dem MCP-Server passiert das automatisch: `glab` fügt `--output json` für\njeden Befehl hinzu, der das unterstützt. Beim direkten Arbeiten im Terminal\neinfach das Flag selbst ergänzen:\n\n```shell\n# Offene Issues für Triage abrufen\nglab issue list --label \"needs-triage\" --output json\n\n# Pipeline-Status prüfen\nglab ci status --output json\n\n# Vollständige MR-Details abrufen\nglab mr view 456 --output json\n```\n\nDie JSON-Ausgabe wurde in letzten Releases erheblich erweitert. Sie deckt jetzt\nCI-Status, Milestones, Labels, Releases, Schedules, Cluster-Agenten, Work\nItems, MR-Genehmiger, Repository-Mitwirkende und mehr ab. Was `glab` abrufen\nkann, kann die KI sauber verarbeiten.\n\n### Ein echter Workflow\n\n```shell\n$ glab issue list --label \"needs-triage\" --milestone \"17.10\" \\\n--output json\n```\n\n```text\nAgent: I found 2 unassigned bugs in the 17.10 milestone that need triage:\n1. #902 — Pipeline fails on merge to main (opened 5 days ago)\n2. #903 — Auth token not refreshing on expiry (opened 4 days ago)\nBoth are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?\n```\n\n\n## Der Agent ist keineswegs auf eingebaute Befehle beschränkt\n\nDie nativen Befehle von `glab` decken die gängigsten Workflows ab – aber der\nAgent ist nicht darauf beschränkt. Über `glab api` hat er authentifizierten\nZugriff auf die vollständige GitLab REST- und GraphQL-API-Oberfläche, mit\nderselben Session, ohne zusätzliche Credentials oder Konfiguration.\n\nDas ist ein wesentlicher Unterschied. Die meisten CLI-Werkzeuge beschränken\nsich auf das, was ihre Befehle abbilden. Mit `glab` gilt: Wenn GitLabs API es\nunterstützt, kann der Agent es tun – immer aus einem vertrauenswürdigen,\nauthentifizierten Kontext heraus.\n\nEin praktisches Beispiel: nur die Liste der geänderten Dateien in einem MR\nabrufen, bevor entschieden wird, welche Diffs vollständig geladen werden:\n\n```shell\n# Geänderte Dateipfade abrufen – leichtgewichtig, noch kein Diff-Inhalt\nglab api \"/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100\" \\\n| jq '.[].new_path'\n\n# Dann nur die spezifische Datei laden, die der Agent benötigt\nglab api \"/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100\" \\\n| jq '.[] | select(.new_path == \"path/to/file.go\")'\n```\n\n```text\n\"internal/auth/token.go\"\n\"internal/auth/token_test.go\"\n\"internal/oauth/refresh.go\"\n```\n\nFür alles, was die REST API nicht abdeckt (Epics, bestimmte Work-Item-Abfragen,\nkomplexe projektübergreifende Daten), bietet `glab api graphql` die vollständige\nGraphQL-Schnittstelle:\n\n```shell\nglab api graphql -f query='\n{\n  project(fullPath: \"gitlab-org/gitlab\") {\n    mergeRequest(iid: \"12345\") {\n      title\n      reviewers { nodes { username } }\n    }\n  }\n}'\n```\n\n```json\n{\n  \"data\": {\n    \"project\": {\n      \"mergeRequest\": {\n        \"title\": \"feat: add OAuth2 support\",\n        \"reviewers\": {\n          \"nodes\": [\n            { \"username\": \"dmurphy\" },\n            { \"username\": \"sreeves\" }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\nEin einziger, authentifizierter Einstiegspunkt zu allem, was GitLab\nbereitstellt – ohne Token-Jonglieren, separate API-Clients oder\nKonfigurationsaufwand.\n\n\n## Was als Nächstes kommt – und Feedback\n\nZwei Verbesserungen, an denen aktiv gearbeitet wird, werden `glab` für\nAgenten-Workflows noch nützlicher machen:\n\n**Auf Agenten abgestimmter Hilfetext.** Heute ist die `--help`-Ausgabe für\nMenschen am Terminal geschrieben. Sie wird aktualisiert, um für jeden\ninteraktiven Befehl die nicht-interaktive Alternative anzuzeigen, Befehle mit\n`--output json`-Unterstützung zu kennzeichnen und Hilfe generell zu einer\nnützlichen Ressource für Agenten zu machen, die Fähigkeiten zur Laufzeit\nentdecken – nicht nur für Menschen.\n\n**Besser maschinenlesbare Fehlermeldungen.** Wenn heute etwas schiefläuft,\nerhalten Agenten dieselben menschenlesbaren Fehlermeldungen wie\nTerminal-Nutzende. Das wird geändert: Fehler im JSON-Modus geben strukturierte\nAusgaben zurück, die dem Agenten die Informationen liefern, die er braucht, um\nFehler sauber zu behandeln, intelligent zu wiederholen oder den richtigen\nKontext zurückzugeben.\n\nBeide Punkte sind in aktiver Entwicklung. Wer `glab` bereits mit einem\nKI-Werkzeug einsetzt, ist genau die Zielgruppe, deren Erfahrungen uns\ninteressieren.\n\n* **Welche Reibungspunkte gibt es?** Befehle, die sich in Agenten-Kontexten\n  nicht gut verhalten, Fehlermeldungen ohne Handlungsanleitung, Lücken in der\n  JSON-Ausgabe. Feedback ist willkommen.\n\n* **Welche Workflows wurden erschlossen?** Reale Nutzungsmuster helfen dabei,\n  Prioritäten für die weitere Entwicklung zu setzen.\n\nDie Diskussion findet im\n[Feedback-Issue](https://gitlab.com/gitlab-org/cli/-/issues/8177) statt –\ndort wird die Roadmap für Agenten-Freundlichkeit gestaltet, und Beiträge haben\ndort den direktesten Einfluss. Wer eine spezifische Lücke gefunden hat,\nkann ein [Issue öffnen](https://gitlab.com/gitlab-org/cli/-/issues/new). Wer\neinen Fix im Sinn hat: Beiträge sind willkommen. Details unter\n[CONTRIBUTING.md](https://gitlab.com/gitlab-org/cli/-/blob/main/CONTRIBUTING.md).\n\nDas GitLab CLI stand schon immer dafür, Entwickler(inne)n mehr Kontrolle über ihren\nWorkflow zu geben. Da KI ein immer größerer Teil der täglichen Arbeit wird,\nbedeutet das, `glab` zur bestmöglichen Schnittstelle zwischen KI-Werkzeugen\nund GitLab-Projekten zu machen. Wir stehen am Anfang – und freuen uns darauf,\nden nächsten Teil gemeinsam zu gestalten.\n",[23,724,737],"tutorial",{"featured":29,"template":15,"slug":739},"give-your-ai-agent-direct-structured-gitlab-access-with-glab-cli",{"content":741,"config":749},{"title":742,"description":743,"authors":744,"heroImage":733,"date":746,"body":747,"category":11,"tags":748},"GitHubs neue Copilot-Richtlinie: Was regulierte Unternehmen jetzt prüfen müssen","Warum GitLabs Datenverwaltungsansatz strukturell anders ist – und was GitHubs neue Copilot-Richtlinie für regulierte Unternehmen bedeutet.",[745],"Allie Holland","2026-04-20","GitHub hat kürzlich angekündigt, wie Interaktionsdaten von Copilot-Nutzenden\nkünftig verwendet werden. Ab dem 24. April 2026 werden Daten aus Copilot Free,\nPro und Pro+ standardmäßig zum Training von KI-Modellen genutzt, sofern\nNutzende nicht aktiv widersprechen. Betroffen sind Eingaben, Ausgaben,\nCode-Snippets und zugehöriger Kontext. Copilot Business und Enterprise sind\naufgrund bestehender Vertragskonditionen ausgenommen.\n\nFür Unternehmen in regulierten Branchen wirft diese Änderung Fragen auf, die\nüber individuelle Entwicklerpräferenzen weit hinausgehen. Sie zwingt zu einer\ngrundlegenden Prüfung, die Führungskräfte aus Engineering und IT-Sicherheit\njedem KI-Anbieter in ihrem Stack stellen sollten: Werden unsere Daten für\nKI-Training verwendet?\n\nGitLabs Antwort lautet: Nein. GitLab trainiert KI-Modelle nicht mit\nKundendaten – auf keiner Preisstufe. KI-Anbieter sind vertraglich verpflichtet,\nKundeneingaben und -ausgaben nicht für eigene Zwecke zu verwenden. Das\n[GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/)\nmacht diese Zusage prüfbar. Eine zentrale Dokumentation zeigt, welche Modelle\nwelche Funktionen betreiben, wie Daten verarbeitet werden, welche\nUnterauftragsverarbeiter beteiligt sind und wie lange Daten gespeichert werden.\nDas AI Transparency Center dokumentiert außerdem den Compliance-Status jeder\nFunktion – einschließlich der Bestätigung, dass GitLabs aktuelle KI-Funktionen\nnicht als Hochrisikosysteme im Sinne des EU AI Act eingestuft werden. Diesen\nStandard hat GitLab-CEO Bill Staples\n[wiederholt bekräftigt](https://www.linkedin.com/posts/williamstaples_gitlab-1810-agentic-ai-now-open-to-even-activity-7443280763715985408-aHxf)\n– er spiegelt GitLabs Unternehmensmission und das\n[Trust Center](https://trust.gitlab.com/) wider.\n\n\n## Was die Richtlinienänderung tatsächlich bedeutet\n\nGitHub gibt zudem an, dass die Daten mit verbundenen Unternehmen – darunter\nMicrosoft – für KI-Entwicklungszwecke geteilt werden können.\n\nQuellcode zählt häufig zum sensibelsten geistigen Eigentum eines Unternehmens.\nEr kann proprietäre Geschäftslogik abbilden, interne Systemarchitekturen\noffenlegen oder Datenflüsse berühren, die strengen Aufbewahrungs- und\nZugriffsrichtlinien unterliegen. Wenn dieser Code einen KI-Assistenten\ndurchläuft und zum Training von Modellen verwendet wird, die auch Wettbewerbern\ndienen, werden Anbieterdatenpraktiken zu einem konkreten IP-Risiko. Regulierte\nBranchen weltweit – von Finanzdienstleistungen über Gesundheitswesen bis zum\nöffentlichen Sektor – operieren unter Compliance-Anforderungen, die genau\ndiesen Punkt adressieren: dokumentierte, prüfbare Kontrolle über den Umgang\nDritter mit sensiblen Daten.\n\nEine Anbieterrichtlinie, die Datenstandardeinstellungen ändert, ein aktives\nWiderspruchsrecht erfordert und je nach Vertragsstufe unterschiedliche\nSchutzstandards bietet, erzeugt genau die Art unkontrollierbarer Variablen,\ndie Compliance-Teams nicht akzeptieren können. Der\n[Digital Operational Resilience Act (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)\n– seit Januar 2025 für europäische Finanzinstitute verbindlich – macht dies\nexplizit: Wesentliche Änderungen an IT-Drittanbieterbeziehungen erfordern\ndokumentierte Bewertung und Nachverfolgung.\n\n\n## Was regulierte Unternehmen von KI-Anbietern tatsächlich benötigen\n\nRegulierte Unternehmen diskutieren nicht mehr grundsätzlich, ob KI in\nEntwicklungs-Workflows eingesetzt werden soll. Der Fokus liegt darauf, dies so\nzu tun, dass es gegenüber Aufsichtsbehörden, Vorständen und Kunden vertretbar\nist. Dabei sind branchenübergreifend konsistente Anforderungen sichtbar\ngeworden.\n\n**Vertragliche Klarheit.** Regulierte Unternehmen benötigen spezifische,\ndokumentierte und bedingungslose Zusagen darüber, was mit ihren Daten geschieht\n– nicht etwas, das je nach Vertragsstufe variiert oder eine Handlung vor einem\nStichtag erfordert.\n\n**Prüfbarkeit.** IT-Risikomanagement-Frameworks verlangen von Unternehmen, die\neingesetzten KI-Systeme zu verstehen und zu validieren: die Trainingsdaten\nhinter diesen Modellen und die beteiligten Drittparteien. Anbieter, die diese\nFragen nicht beantworten können, erzeugen Dokumentationsrisiken für die\nOrganisationen, die sich auf sie stützen.\n\n**Trennung von Anbieterinteressen.** Wenn ein KI-Anbieter Modelle auf Basis\nvon Kundennutzungsdaten trainiert, werden Code und Workflows zu Eingaben für\nein System, das auch Wettbewerbern dient. Für Institutionen mit proprietären\nHandelsalgorithmen, Underwriting-Modellen oder Betrugserkennungssystemen ist\ndas ein konkretes IP-Risiko.\n\n\n## GitLabs Position zur KI-Datenverwaltung\n\nGitLab verwendet Kundendaten nicht zum Training von KI-Modellen. Diese Zusage\ngilt auf jeder Preisstufe; KI-Anbieter sind vertraglich verpflichtet, Eingaben\nund Ausgaben, die mit GitLab-Kunden verbunden sind, nicht für eigene Zwecke zu\nverwenden.\n\nDies ist eine bewusste architektonische und richtlinienbezogene Entscheidung –\nkein Merkmal einer bestimmten Preisstufe. Wie GitLabs\n[Beitrag zur Enterprise-Unabhängigkeit](https://about.gitlab.com/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/)\nfesthält, ist Datenverwaltung zu einem \"zunehmend kritischen Faktor bei\nUnternehmensentscheidungen\" geworden – getrieben durch nationale und regionale\nDatenschutzgesetze und wachsende Bedenken hinsichtlich der Kontrolle über\nsensibles geistiges Eigentum.\n\nGitLab ist cloud-neutral und modell-neutral und unterstützt\nSelf-Hosted-Deployments ohne kommerzielle Bindung an einen einzelnen\nCloud-Anbieter oder ein Large Language Model. Diese Unabhängigkeit ist für\nregulierte Unternehmen relevant, die Risiken durch Anbieterkonzentration\nbewerten. Der\n[AI Continuity Plan](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/)\ndokumentiert, wie Anbieterveränderungen gehandhabt werden – einschließlich\nwesentlicher Änderungen daran, wie KI-Anbieter Kundendaten behandeln. Er ist\neine direkte Antwort auf die Governance-Anforderungen unter Frameworks wie\n[DORA](https://handbook.gitlab.com/handbook/legal/dora/).\n\n\n## Die Governance-Lücke, die KI-Teams schließen müssen\n\nGitHubs Richtlinienaktualisierung macht deutlich: Für Unternehmen in\nregulierten Branchen ist das genaue Verständnis des Datenumgangs eines\nKI-Werkzeugs eine Voraussetzung für dessen Einsatz. Das bedeutet, Anbietern\nklare, dokumentierte Antworten auf folgende Fragen abzuverlangen:\n\n1. Werden unsere Daten zum Training von KI-Modellen verwendet?\n2. Wer sind Ihre KI-Modell-Unterauftragsverarbeiter?\n3. Was geschieht, wenn ein Anbieter seine Datenpraktiken ändert?\n4. Lässt sich ein Deployment realisieren, das alle KI-Verarbeitung innerhalb\n   der eigenen Infrastruktur hält?\n5. Welche Haftungsübernahme wird für KI-generierte Ausgaben angeboten?\n\nAnbieter, die diese Fragen klar beantworten und die Antworten in prüfbarer\nForm dokumentieren, sind Anbieter, auf die sich aufbauen lässt.\n**Wer das nicht kann, schafft Compliance-Risiken bei jedem Policy-Update.**\nWenn ein Anbieter Datenpraktiken mit 30 Tagen Ankündigungsfrist ändern kann,\nist das kein partnerschaftlicher Rahmen für regulierte Unternehmen – das ist\nein strukturelles Compliance-Risiko.\n\n> Mehr zu GitLabs Ansatz für KI-Governance im\n> [GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/).\n",[23,724],{"featured":14,"template":15,"slug":750},"github-copilots-new-policy-for-ai-training-is-a-governance-wake-up-call",{"promotions":752},[753,766,777,789],{"id":754,"categories":755,"header":756,"text":757,"button":758,"image":763},"ai-modernization",[11],"Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":759,"config":760},"Get your AI maturity score",{"href":761,"dataGaName":762,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":764},{"src":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":767,"categories":768,"header":769,"text":757,"button":770,"image":774},"devops-modernization",[724,40],"Are you just managing tools or shipping innovation?",{"text":771,"config":772},"Get your DevOps maturity score",{"href":773,"dataGaName":762,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":775},{"src":776},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":778,"categories":779,"header":781,"text":757,"button":782,"image":786},"security-modernization",[780],"security","Are you trading speed for security?",{"text":783,"config":784},"Get your security maturity score",{"href":785,"dataGaName":762,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":787},{"src":788},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":790,"paths":791,"header":794,"text":795,"button":796,"image":801},"github-azure-migration",[792,793],"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":797,"config":798},"See how GitLab compares to GitHub",{"href":799,"dataGaName":800,"dataGaLocation":248},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":802},{"src":776},{"header":804,"blurb":805,"button":806,"secondaryButton":811},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":807,"config":808},"Kostenlosen Test starten",{"href":809,"dataGaName":54,"dataGaLocation":810},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":56,"config":812},{"href":58,"dataGaName":59,"dataGaLocation":810},1777493573693]