Veröffentlicht am: 21. Mai 2026

6 Minuten Lesezeit

CI-Komponentennutzung in deinem Unternehmen nachverfolgen

Mit GitLab 19.0 siehst du, wie deine gemeinsam genutzten CI-Komponenten in deinem Unternehmen eingesetzt werden – und kannst gezielt handeln.

Wenn dein Plattformteam standardisierte Pipeline-Komponenten veröffentlicht, kennst du das Problem wahrscheinlich: Sobald sie im Einsatz sind, verlierst du den Überblick. Du kannst nicht sehen, ob sie tatsächlich genutzt werden, wer welche Version verwendet oder welche Projekte noch veraltete Versionen einsetzen, die dein Unternehmen Sicherheitsrisiken aussetzen.

Mit der neuen Ansicht Components Analytics im CI/CD-Katalog von GitLab 19.0 erhält dein Team Transparenz und wichtige Nutzungsdaten darüber, wie CI/CD-Komponenten im gesamten Unternehmen eingesetzt werden. Nutzungszahlen und Adoptionsdaten sind in allen Tarifen verfügbar. Mit Ultimate kannst du jede Komponente im Detail analysieren und genau sehen, welche Projekte welche Versionen verwenden.

Da KI immer mehr Pipelines generiert, die in die Produktion gelangen, ist diese Transparenz wichtiger denn je.

Die Transparenzlücke bei gemeinsam genutztem CI

Der GitLab CI/CD-Katalog bietet DevSecOps- und Platform-Engineering-Teams einen zentralen Ort, um versionierte, wiederverwendbare Pipeline-Komponenten zu veröffentlichen, die jedes Projekt mit einer einzigen include-Referenz einbinden kann. Kein Copy-and-Paste, keine manuellen Updates über Hunderte von Repos, kein Rätselraten darüber, welche Vorlage die einzige Quelle der Wahrheit ist. Verteilung: gelöst.

Aber sobald eine Komponente im Einsatz ist, verschwindet die Transparenz – und die Folgen sind nicht nur betrieblicher Natur. Sicherheitsfixes in gemeinsam genutzten Komponenten werden nicht automatisch weitergegeben, sodass veraltete, anfällige Versionen in Produktions-Pipelines verbleiben – mit einem Schadensradius, den niemand messen kann, bis etwas schiefgeht. Wenn das nächste Mal eine Sicherheitslücke in einer weit verbreiteten Komponente bekannt wird, sollte die Frage „Wie stark sind wir betroffen?“ nicht eine Woche manueller Prüfung erfordern.

Components Analytics zeigt dir, was tatsächlich läuft

Components Analytics schließt diese Lücke mit zwei Ansichten: einer übergeordneten Nutzungsansicht, die in allen Tarifen verfügbar ist, und einer komponentenbezogenen Detailansicht in Ultimate.

Übergeordnete Adoptionsansicht

Die übergeordnete Adoptionsansicht zeigt den Betreuer(inne)n von Komponenten, wie weit verbreitet ihre Komponenten im Unternehmen genutzt werden. Für jede Katalogressource, die du betreust, siehst du:

  • Die zuletzt veröffentlichte Version
  • Die Anzahl der einzelnen Projekte, die in den letzten 30 Tagen eine Komponente daraus abgerufen haben
  • Welche Komponenten in dieser Version verfügbar sind.

CI/CD Catalog

Auf einen Blick siehst du, welche deiner Komponenten weit verbreitet sind und welche stillschweigend aufgegeben wurden. Das ist nützlich für die Priorisierung der Wartung, die Planung von Abkündigungen und die Begründung weiterer Investitionen in die gemeinsame CI-Infrastruktur.

Diese übergeordnete Ansicht wurde mit GitLab 18.9 veröffentlicht und ist in allen Tarifen verfügbar, einschließlich des kostenlosen Tarifs. Wenn du Komponenten im CI/CD-Katalog betreust, kannst du sie sofort nutzen. Du erreichst sie über Explore > CI/CD Catalog > Analytics.

Für Teams, die Nachweise darüber benötigen, was wo läuft – sei es für die Reaktion auf Sicherheitsvorfälle, Compliance-Audits oder umfangreiche Refactorings – bietet GitLab Ultimate die komponentenbezogene Detailansicht.

Detailansicht der Komponentennutzung

Wenn die übergeordnete Ansicht die Frage „Wie weit verbreitet ist meine Komponente?“ beantwortet, beantwortet die Detailansicht die Frage „Welche Projekte verwenden welche Versionen, und wo muss ich handeln?“

Mit der neuen Components Analytics in GitLab Ultimate kannst du jede Katalogressource öffnen, die du betreust, und genau sehen, welche Projekte in den letzten 30 Tagen eine ihrer Komponenten in einer Pipeline eingebunden haben, welche Version jedes Projekt verwendet und welche Versionen veraltet sind. Jedes Projekt ist klar als aktuell oder veraltet gekennzeichnet, sodass du auf einen Blick weißt, wo du ansetzen musst.

Components Analytics view

Wenn du einen Fix in v2.1 einer Komponente veröffentlicht hast, zeigt dir die Detailansicht genau, welche Projekte noch auf v1.x festgelegt sind – so kannst du MRs erstellen, die Betreuer(innen) direkt benachrichtigen oder eskalieren. Wenn das nächste Mal eine Sicherheitslücke in einer weit verbreiteten Komponente bekannt wird, ist „Wie stark sind wir betroffen?“ eine Antwort in einem einzigen Tab statt einer Woche manueller Prüfung.

Die Detailansicht unterstützt auch die größeren Entscheidungen: ob ein Refactoring sich auf Hunderte von Pipelines auswirkt, ob es sicher ist, eine ältere Version abzukündigen, oder ob der Sicherheitsfix, den du letzte Woche veröffentlicht hast, tatsächlich in den relevanten Projekten übernommen wurde.

Integrierte Transparenz, die du anderswo nicht bekommst

GitHub Actions, CircleCI Orbs und Jenkins Shared Libraries bieten alle Pipeline-Wiederverwendbarkeit, aber keine davon bietet die native Nutzungstransparenz, die Components Analytics hinzufügt.

  • GitHub Actions hat keine native Katalog-Analyseschicht. Um zu wissen, welche wiederverwendbaren Workflows in deinem Unternehmen im Einsatz sind und in welchen Versionen, musst du eigene interne Tools oder Dokumentation erstellen und pflegen.
  • Das Insights-Dashboard von CircleCI deckt Pipeline-Performance-Metriken ab, bietet aber keine native Ansicht, die zeigt, welche Orbs in deinem Unternehmen von welchen Teams oder in welchen Versionen genutzt werden.
  • Jenkins Shared Libraries erfordern eigene Tools, um die Komponentennutzung überhaupt nachzuverfolgen.

Wiederverwendbarkeit ohne Transparenz bedeutet, dass du nicht nachweisen kannst, dass deine Standards eingehalten werden, und die Rendite deiner Plattforminvestition nicht messen kannst. GitLab ist die einzige Plattform, die einen verwalteten CI-Komponentenkatalog mit nativen Analysen kombiniert, die zeigen, wo deine Standards laufen – und wo nicht.

Governance für KI-generierte Pipelines

Der CI/CD-Katalog hat Plattformteams eine Möglichkeit gegeben, Abweichungen zu reduzieren und Standards durchzusetzen. Components Analytics ist die Transparenzschicht, die gemeinsam genutztes CI von einer Sammlung von YAML-Vorlagen, die du veröffentlichst und vergisst, in eine Infrastruktur verwandelt, die du prüfen, auf die du reagieren und der du vertrauen kannst.

Da KI immer mehr Code in deinem Unternehmen generiert, helfen der CI/CD-Katalog und Components Analytics gemeinsam dabei, automatisierte Workflows zu skalieren. Tools wie der CI Expert Agent können Pipelines generieren, die von Anfang an den GitLab-Standards entsprechen – aber nur Components Analytics zeigt dir, ob diese Standards tatsächlich in der Produktion laufen.

Self-Managed- und Dedicated-Kund(inn)en können diesen genehmigten Satz von Standards mit von GitLab.com gespiegelten Komponenten zusammen mit intern erstellten Komponenten aufbauen und so regulierten und Air-Gapped-Umgebungen dieselbe kuratierte Basis bieten.

Sieh dir an, welche CI/CD-Komponenten in deinem Katalog laufen

Wenn du Komponenten im CI/CD-Katalog betreust, sind Adoptionsmetriken jetzt in allen Tarifen verfügbar – klicke einfach auf Explore > CI/CD Catalog > Analytics.

Die Detailansicht der Komponentennutzung, die die Frage „Welche Projekte verwenden welche Versionen, und wo muss ich handeln?“ beantwortet, ist in GitLab Ultimate verfügbar. Starte eine kostenlose Ultimate-Testversion oder kontaktiere unser Team, um sie für dein Unternehmen zu aktivieren.

Erfahre mehr über die Neuerungen in GitLab 19.0

Feedback erwünscht

Hat dir dieser Blogbeitrag gefallen? Hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab-Community-Forum und lass andere an deinen Eindrücken teilhaben.

Feedback teilen

Beginne noch heute, schneller zu entwickeln

Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.