
9. GitLab im regulierten Enterprise-Stack: Zwischen GA, Beta und Credits
Die Folge zeigt, warum GitLab in regulierten Enterprise-Umgebungen nicht als Ersatz, sondern als Ausführungsschicht neben bestehenden Systemen wie Polarion, Artifactory und Nexus funktioniert. Außerdem geht es um klare GA-/Beta-Grenzen, agentische Security-Workflows mit Duo Agent Platform und die Frage, wie Verbrauchsmodelle wie GitLab Credits in starren Beschaffungsprozessen bestehen können.
Chapter 1
Die Monolith Illusion und der Polarion Faktor
Otto
Wenn du bei Thales in den Konferenzraum gehst und sagst, GitLab ersetzt jetzt jedes einzelne Entwicklerwerkzeug im Konzern, dann fliegst du in hohem Bogen raus. Sofort.
Leonie
Weil da draußen in der Realität Systeme stehen wie Siemens Polarion. Für formale Systemanforderungen, oder eben JFrog Artifactory und Sonatype Nexus für Artefaktverwaltung. Die sind tief in den zertifizierten Prozessen verwurzelt.
Otto
Genau das. Man kann nicht einfach reinkommen und so tun, als gäbe es keine Vorgeschichte. GitLab ist in so einem Umfeld nicht der große Radiergummi, der upstream alles wegbügelt. Es ist die Ausführungsschicht.
Leonie
Die Verbindung zwischen diesen Welten, oder? Polarion hält die regulierten Anforderungen fest, und GitLab nimmt die auf, verknüpft sie mit Issues, Merge Requests, CI CD Pipelines und hält den Audit-Trail sauber.
Otto
Unter einem einzigen Berechtigungsmodell. Und das ist ja kein theoretisches Luftschloss. Thales startet bei dieser Diskussion absolut nicht bei null. Die haben bereits eine dokumentierte GitLab Ultimate Beziehung.
Leonie
Stimmt, die Avionik-Sparte mit FlytEDGE. Da gab es doch diese konkreten Kennzahlen aus der Fallstudie: achtmal schnellere Software-Updates, vierzigmal schnelleres Projekt-Setup und neunzig Prozent niedrigere Build-Infrastrukturkosten.
Otto
Dazu noch ein voller Entwicklungstag pro Person und Monat eingespart. Wer da reingeht und versucht, Thales Ultimate neu zu verkaufen, hat seine Hausaufgaben schlicht nicht gemacht.
Leonie
Es geht darum, das bestehende Betriebsmodell zu vertiefen. Wie dockt man daran an, statt alles umwerfen zu wollen?
Chapter 2
Die GA Grenze Warum Roadmaps im Ruestungssektor giftig sind
Otto
Und genau an der Stelle kommt die härteste Regel für Enterprise-Panels ins Spiel. Verkaufe niemals eine Roadmap als fertiges Produkt. Im Rüstungsbereich ist das tödlich.
Leonie
Du meinst die Verwechslung von General Availability und Beta? Wenn jemand eine private Beta als voll einsatzfähig pitcht, verliert das Gremium sofort jedes Vertrauen.
Otto
Absolut. Nehmen wir die Duo Agent Platform, kurz DAP. Die Plattform an sich und Kern-Flows wie der Fix CI CD Pipeline Flow sind GA. Aber der neuere Security Review Flow ist nach wie vor Beta. Das muss man glasklar benennen.
Leonie
Wie läuft denn dieser Fix CI CD Pipeline Flow in der Praxis ab, wenn er wirklich GA ist?
Otto
Er schaut sich die Pipeline-Logs an, analysiert die Skriptfehler, prüft die Änderungen im Merge Request und den Repository-Kontext. Dann schlägt er entweder Inline-Korrekturen vor oder erstellt direkt einen Merge Request mit dem Fix.
Leonie
Und wenn der Sicherheitskontext heikel ist oder die Datenbasis zu dünn?
Otto
Dann stoppt der Agent ganz bewusst und hinterlässt nur einen erklärenden Kommentar für den Ingenieur, statt eigenmächtig Code reinzudrücken. Genau diese Zurückhaltung braucht man in sicherheitskritischen Bereichen.
Leonie
Erinnert mich an eine Demo vor ein paar Jahren bei einem Industriekunden. Ein Kollege wollte unbedingt glänzen, hat ein brandneues Beta-Feature vorgeführt, das angeblich alles automatisiert. Mitten im Termin lief der Agent gegen die restriktiven Berechtigungsgrenzen des Kunden und ist krachend abgestürzt.
Otto
Kalter Schweiß im Nacken, oder?
Leonie
Absolut. Zehn Sicherheitsingenieure schauen dich mit verschränkten Armen an, und du weißt, der Termin ist gelaufen. Deswegen: Beta gehört als Beta deklariert, ohne Ausnahme.
Chapter 3
Nach dem Scanner Schock Triage Automatisierung und GitLab Credits
Otto
Das bringt uns direkt zum nächsten Punkt: Security. Thales nutzt mit Ultimate ja schon SAST, DAST, Secret Detection und Software Composition Analysis. Wenn man da reingeht und sagt: Wir haben noch einen Scanner, winken die ab.
Leonie
Weil mehr Scanner am Ende nur mehr Treffer bedeuten. Und mehr Treffer bedeuten einen gigantischen Berg an manueller Triage-Arbeit für die Teams. Niemand will noch mehr Listen mit tausend Warnungen.
Otto
Der echte Engpass ist die Zeit nach der Erkennung. Genau da greifen die agentischen GA-Flows in Ultimate: False-Positive-Erkennung bei SAST und automatisierte Schwachstellenbehebung. Da spart man plötzlich reale Ingenieursstunden ein.
Leonie
Aber wie bezahlt Thales das technisch? Da greift doch dieses neue Verbrauchsmodell, die GitLab Credits, richtig?
Otto
Richtig. Credits sind die standardisierte Währung für die agentischen Workflows der Duo Agent Platform. Ein simpler Code Suggestion Call verbraucht einen winzigen Bruchteil, während eine komplette Pipeline-Analyse oder Schwachstellenbehebung modellbasiert abgerechnet wird.
Leonie
Das wird auf Top-Level-Gruppenebene gebucht und nicht pro Projekt, oder? Man hat inkludierte monatliche Credits pro Ultimate-Nutzer, kann aber auch einen geteilten Commitment-Pool anlegen.
Otto
Ganz genau. Aber hier liegt das eigentliche Beschaffungsdilemma für Organisationen wie Thales. Rüstung und Luftfahrt budgetieren traditionell in starren, jährlichen Pro-Kopf-Lizenzen. Feste Plätze, feste Rechnungen.
Leonie
Und jetzt kommt eine Technologie, bei der Agenten rund um die Uhr eigenständig Arbeit verrichten und dabei variable Token verbrauchen. Wie soll ein regulierter Einkauf das sauber planen?
Otto
Das ist die offene Frage. Wenn die Verteidigungsindustrie an alten Pro-Kopf-Modellen festhält, sperrt sie autonome Systeme fast zwangsläufig aus. Oder zwingt uns das am Ende dazu, Software-Entwicklung künftig komplett nach ergebnisbasiertem Output zu bewerten?