Datadog CI/CD Optimization nimmt langsame Pipelines, instabile Tests und CI-Kosten ins Visier

Wo die CI-Zeit tatsächlich bleibt

Laut Datadog erhöht KI-gestützte Entwicklung das Tempo, mit dem Teams Code produzieren. Das bedeutet mehr Pull Requests, Builds, Tests und Pipeline-Ausführungen. Langsame Jobs lassen Entwickler und Coding-Agenten auf Feedback warten, instabile Fehlschläge kosten durch Wiederholungen und Fehlersuche Zeit, und unnötig ausgeführte Tests treiben den Bedarf an Runnern in die Höhe.

CI/CD Optimization erfasst Ausführungszeit, Wartezeit in der Warteschlange, Fehlerraten und Zuverlässigkeitstrends über alle CI-Umgebungen hinweg. Plattform-Teams können anhand dieser Signale die Pipelines und Jobs identifizieren, die den größten Einfluss auf die Auslieferung haben. Von einer einzelnen Ausführung aus lassen sich die Stages und Jobs betrachten, die zur Gesamtdauer beitragen, und Leistungsänderungen mit Commits, Fehlern, Logs, Runnern und Infrastrukturmetriken verknüpfen.

Datadog betont, dass diese Unterscheidung den Weg zur Lösung weise. Ein Job, der auf eine zu knapp dimensionierte Runner-Flotte wartet, profitiert womöglich von mehr Kapazität. Ist ein Job selbst langsamer geworden, deutet das auf eine Änderung bei Code, Abhängigkeiten, Tests oder Infrastruktur hin; dieselbe langsame Arbeit gegen Bezahlung auf mehr Runnern auszuführen, würde dann nichts bringen. CI/CD- und Test-Monitore können Teams zudem alarmieren, wenn Pipelines oder Jobs fehlschlagen oder sich verschlechtern.

Das Unternehmen nennt zwei Kundenergebnisse: Betterment senkte die durchschnittliche Build-Dauer von knapp 40 Minuten auf unter 10 Minuten, The Browser Company verkürzte die Laufzeit seiner CI-Pipeline um 50 Prozent.

Werkzeuge für den Umgang mit instabilen Tests

Schnellere Pipelines helfen nur, wenn Entwickler dem Ergebnis vertrauen. Ein instabiler Test (Flaky Test) kann einen eigentlich gültigen Build rot färben, einen erneuten Lauf auslösen und einen Entwickler zwingen, zu klären, ob der Fehler mit seiner Änderung zusammenhängt. Flaky Management in CI/CD Optimization listet instabile Tests neben Kennzahlen wie Pipeline-Fehlschlägen, verschwendeter CI-Zeit und Fehlerrate auf, damit Teams die Fehler priorisieren können, die am meisten Entwicklerzeit und Rechenleistung kosten.

• Auto Test Retries wiederholt fehlschlagende Tests automatisch bis zu einem konfigurierbaren Limit und stoppt, sobald ein Test besteht oder die Versuche aufgebraucht sind. So lässt ein sporadischer Fehler nicht gleich den ganzen Build scheitern.
• Early Flake Detection und PR Gates sollen verhindern, dass neu eingeführte instabile Tests den Default-Branch erreichen, während Korrekturen noch laufen.
• Flaky Management Explorer verfolgt Fehlschläge durch instabile Tests, dadurch verlorene CI-Zeit, durch automatische Wiederholungen gerettete Pipelines und durch Verbesserungen bei der Testausführung eingesparte Zeit.

Datadog beschreibt die Funktionen als Maßnahmen für verschiedene Phasen im Lebenszyklus eines instabilen Tests: Wiederholungen mindern die unmittelbare Störung, Richtlinien verhindern, dass bekannte Fehler unabhängige Änderungen blockieren, und die Erkennung hilft, den Rückstau nicht weiter wachsen zu lassen.

Weniger Arbeit ausführen, und diese effizienter

Zusätzliche Runner erhöhen die Kapazität, beseitigen aber keine unnötige Arbeit. Wenn jeder Commit eine überdimensionierte Testsuite durchläuft, führt eine größere Flotte irrelevante Tests lediglich schneller und zu höheren Infrastrukturkosten aus.

Test Impact Analysis setzt hier an: Die Funktion ordnet Tests dem Code zu, den sie abdecken, und bestimmt daraus, welche Tests von einer Änderung betroffen sind. Tests, die für die Änderung nicht relevant sind, können übersprungen werden. Datadog nennt als Beispiel einen PR, der nur eine README-Datei aktualisiert und deshalb womöglich keine Anwendungstests ausführen muss.

Test Parallelization beschleunigt anschließend die Tests, die weiterhin laufen müssen. Die Funktion verteilt die Tests nicht nach Anzahl, wodurch ein Runner noch lange Tests abarbeiten kann, während andere längst fertig sind, sondern nach der erwarteten Testdauer. Laut Datadog schätzt sie die optimale Zahl an CI-Workern und teilt die Tests so auf, dass die Validierung möglichst früh und möglichst günstig abgeschlossen ist.

Eine Ansicht für Pipelines und Tests

Datadog zufolge sind der Zustand von Pipelines und der Zustand von Tests oft zwei Sichten auf dasselbe Auslieferungsproblem, und ihre Trennung führe dazu, dass Entwickler Zeit mit dem Abgleich von Daten verbringen. CI/CD Optimization führt beides in derselben Datadog-Oberfläche zusammen, sodass Teams bei der Fehlersuche zwischen Pipeline-Ausführungen, Jobs und Tests wechseln können.

Für Plattform-Teams lautet das Versprechen, dass dieselbe Runner-Flotte bei wachsendem Entwicklungsvolumen mehr Änderungen verarbeiten kann, ohne dass Runner- und Rechenkosten im gleichen Tempo steigen. Für Entwickler und Coding-Agenten bedeutet es ein schnelleres Urteil über jede Änderung. Diese Effekte sind Aussagen von Datadog über das eigene Produkt.