Neue GitLab-Metriken und Registry-Funktionen reduzieren CI/CD-Engpässe

Plattform- und DevOps-Ingenieure verbringen zu viel Zeit damit, Transparenz über fragmentierte Tools hinweg herzustellen und Infrastruktur zu verwalten, die einfach funktionieren sollte.

Zwei neue GitLab-Funktionen, derzeit in der Beta, gehen dieses Problem aus unterschiedlichen Richtungen an – mit demselben Ziel: Praktikern direkte Kontrolle über die CI/CD-Infrastruktur zu geben, auf die sie angewiesen sind, ohne ein weiteres Drittanbieter-Tool einzuführen. Die eine Funktion liefert Job-Performance-Daten direkt dort, wo Pipelines überwacht werden. Die andere vereinfacht das Abrufen von Container-Images aus mehreren Registries mit integriertem Caching.

Beide Funktionen sind jetzt für Feedback offen. Rückmeldungen helfen dabei, die nächsten Entwicklungsschritte zu gestalten.

CI/CD Job Performance Metrics

• Verfügbare Tiers: GitLab Premium, GitLab Ultimate
• Status: Beta mit eingeschränkter Verfügbarkeit auf GitLab.com; verfügbar auf GitLab Self-Managed und GitLab Dedicated bei konfiguriertem ClickHouse

Bislang gibt es keine einfache Möglichkeit zu erkennen, wenn die Laufzeit eines bestimmten Jobs zunimmt oder welche Jobs die Pipeline-Laufzeiten im Hintergrund verlangsamen. Die meisten Teams erstellen entweder eigene Dashboards oder durchsuchen manuell Logs, um grundlegende Fragen zu beantworten:

• Welche Jobs sind am langsamsten?
• Wo steigen die Fehlerquoten?
• Welche Stage ist der eigentliche Engpass?

CI/CD Job Performance Metrics löst das durch ein neues job-fokussiertes Panel auf der CI/CD-Analytics-Seite auf Projektebene.

Für jeden Job in den Pipelines sind folgende Informationen einsehbar:

• Typische (P50, Median) und ungünstigste (P95) Job-Laufzeit für einen schnellen Vergleich zwischen normalem und langsamstem Lauf
• Fehlerquote zur Erkennung instabiler oder unzuverlässiger Jobs
• Job-Name und Stage, standardmäßig für die letzten 30 Tage

Die Tabelle ist sortierbar, nach Job-Name durchsuchbar und paginiert – Plattform-Teams erhalten so eine einheitliche Ansicht für Fragen, die bisher separate Tools oder eigene Berichte erforderten.

Jetzt ausprobieren

• Im Projekt Analysieren > CI/CD-Analyse aufrufen.
• Das CI/CD Job Performance Metrics-Panel suchen und nach Laufzeit oder Fehlerquote sortieren, um die langsamsten oder unzuverlässigsten Jobs zu finden.

Dokumentation

• CI/CD-Analyse – CI/CD Job Performance Metrics

Was als Nächstes kommt

Aktuell wird an einer Stage-Level-Gruppierung gearbeitet, mit der aggregierte Metriken über Build-, Test- und Deploy-Stages hinweg einsehbar sein werden – für ein schnelles Verständnis davon, wo Optimierungsbedarf besteht.

Feedback geben:

• CI/CD Job Performance Metrics Epic

Container Virtual Registry

Tier: GitLab Premium Status: Beta, API-ready in 18.9

Die meisten Unternehmen, die Container-Images in CI/CD-Pipelines abrufen, sind auf mehrere Registries angewiesen: Docker Hub, Harbor, Quay und interne Registries, um nur einige zu nennen. Authentifizierung, Verfügbarkeit und Caching für all diese Registries zu verwalten, ist operativer Aufwand, der Pipelines verlangsamt und Fehleranfälligkeit erhöht.

Die Container Virtual Registry ermöglicht die Erstellung eines einzigen GitLab-Endpunkts, der Images aus mehreren vorgelagerten Container-Quellen mit integriertem Caching abruft.

Statt Zugangsdaten und Verfügbarkeit für jede Registry einzeln in der Pipeline-Konfiguration einzurichten, lässt sich:

• Eine einzelne virtuelle GitLab-Registry als Endpunkt für alle Pipelines konfigurieren
• Mehrere vorgelagerte Registries einbinden (Docker Hub, Harbor, Quay und andere mit Long-Lived-Token-Authentifizierung)
• GitLab Image-Pulls automatisch auflösen lassen, mit Pull-Through-Caching zur Reduzierung von Bandbreitenkosten und verbesserter Zuverlässigkeit

Für Teams, die GitLab als Container-Registry-Ersatz evaluieren, schließt dies eine wesentliche Funktionslücke. Für Teams, die bereits Multi-Registry-Container-Workflows verwalten, zentralisiert es das Image-Management in GitLab und reduziert wiederholte Pulls.

Was die Beta heute unterstützt

• Vorgelagerte Registries mit Long-Lived-Token-Authentifizierung: Docker Hub, Harbor, Quay und andere kompatible Registries
• Pull-Through-Caching, sodass häufig verwendete Images nach dem ersten Abruf von GitLab bereitgestellt werden
• API-first-Konfiguration, UI-Verwaltung in Entwicklung

Cloud-Provider-Registries mit IAM-Authentifizierung (wie Amazon Elastic Container Registry, Google Artifact Registry und Azure Container Registry) werden für zukünftige Iterationen berücksichtigt.

Heute testen

• Die Container Virtual Registry ist in 18.9 API-ready.
• SaaS (GitLab.com): Zugang über den CSM anfragen oder im unten verlinkten Feedback-Issue kommentieren, um das Feature-Flag für die eigene Gruppe zu aktivieren.
• Self-managed: Feature-Flag aktivieren und die virtuelle Registry über die API konfigurieren.

Dokumentation

• Container Virtual Registry API
• Container-Images aus der virtuellen Registry abrufen

Walkthrough der Container Virtual Registry Beta:

Feedback geben:

• Feedback-Issue zur Container Virtual Registry

Mitgestalten

Alle in der GitLab-Community sind Mitwirkende. Diese Betas wurden auf Basis von Community-Anfragen entwickelt.

• CI/CD Job Performance Metrics entstand aus dem Bedarf von Teams, die keine einfache Möglichkeit hatten zu erkennen, wenn Build-Zeiten in die falsche Richtung tendierten oder welche Jobs die Pipeline-Zuverlässigkeit beeinträchtigten.
• Container Virtual Registry entstand aus Anfragen von Enterprise-Kunden, die mehrere Registries verwalteten und Tool-Sprawl sowie Bandbreitenkosten reduzieren wollten, während sie GitLab als zentrale Registry evaluierten.

Rückmeldungen gestalten, was als nächstes entwickelt wird. Eine oder beide Betas ausprobieren und Erfahrungen in den verlinkten Feedback-Issues teilen.

Dies ist der erste Beitrag in einer Reihe von Core-DevOps-Betas, die im Laufe des Jahres vorgestellt werden.