Generative KI bedeutet einen monumentalen Wandel in der Softwareindustrie, da sie die Entwicklung, die Sicherheit und den Betrieb von Software vereinfacht. Unsere neue Blog-Reihe, von unseren Produkt- und Entwicklungsteams, gibt einen Einblick darin, wie wir die KI-Funktionalitäten entwickeln, testen und bereitstellen, die in deinem Unternehmen benötigt werden. Lerne neue Funktionen innerhalb von GitLab Duo kennen und erfahre, wie diese DevSecOps-Teams dabei helfen werden, bessere Ergebnisse für Kund(inn)en zu erzielen.
Hattest du schon einmal eine defekte CI/CD-Pipeline und musstest deinen DevSecOps-Workflow unterbrechen oder sogar das Deployment verzögern, um die Ursache herauszufinden? Wenn bei der Entwicklung von Software etwas schief läuft, müssen Entwickler(innen) traditionellerweise die Fehler selbst beheben, Logdatei über Logdatei durchforsten und oft viele Behebungsversuche durchführen. Mit der Ursachenanalyse von GitLab Duo, die Teil unserer Suite aus KI-Funktionen ist, hat das Rätselraten nun ein Ende, denn diese findet für dich die Ursache einer defekten CI/CD-Pipeline. In diesem Artikel erfährst du, was die Ursachenanalyse ist und wie du die KI-Funktionen von GitLab Duo in deinen DevSecOps-Workflow einbauen kannst.
Entdecke die Zukunft von KI-gestützter Softwareentwicklung mit unserem virtuellen Launch-Event zu GitLab 17. Jetzt ansehen!
Was ist eine Ursachenanalyse?
Die Ursachenanalyse von GitLab Duo ist eine KI-Funktionalität, die dir dabei hilft, die Grundursache eines fehlerhaften CI/CD-Joblauf herauszufinden. Sie analysiert die Protokolle und schlägt dir dann Möglichkeiten zur Behebung vor. Während die Ursachenanalyse oft im Incident Management angesiedelt ist, sind ihre Workflows und die Fehlersuche Teil eines jeden DevSecOps-Workflows. Ops-Teams, Adminstrator(inn)en und Plattformentwickler(innen) stehen durch Bereitstellungsprobleme, die durch Infrastructure as Code (IaC) entstehen, Kubernetes- und GitOps-Probleme oder durch die lange Nachverfolgung von Stacktraces und Untersuchung von Pipeline-Fehlschlägen vor Herausforderungen.
Mit der Ursachenanalyse von GitLab Duo nutzen alle dasselbe Interface. Mit Hilfe von KI werden Fehler zusammengefasst, analysiert und Lösungsvorschläge gemacht, damit Unternehmen schneller sichere Software veröffentlichen können.
Eine Pipeline kann aus verschiedensten Gründen Fehler aufweisen, darunter Syntax-Fehler im Code, fehlende Abhängigkeiten, auf denen die Pipeline basiert, Testfehler während des Build-Vorgangs, Zeitüberschreitungen bei Kubernetes- und IaC-Bereitstellungen sowie zahlreiche weitere Probleme. Wenn solche Probleme auftreten, liegt es in der Verantwortung von allen, die durch die Pipeline erstellten Logs genauestens zu überprüfen. Bei der Überprüfung der Logs wird dann der detaillierte Output untersucht, um spezifische Fehlschläge aufzudecken und die Ursache der defekten Pipeline zu finden. Die folgende Pipeline hat beispielsweise mehrere fehlgeschlagene Jobs, die untersucht und repariert werden müssen.
Es kann unterschiedlich lange dauern, diese Probleme zu beheben. Das hängt zum Großteil von Faktoren wie den folgenden ab:
- Wie vertraut die Entwickler(innen) mit dem Projekt sind
- Ihr Erfahrungsniveau beim Umgang mit ähnlichen Problemen
- Ihr allgemeines Kenntnislevel in der Fehlerbehebung im Kontext der Pipeline.
Die manuelle Analyse kann unglaublich herausfordernd und zeitaufwändig sein, da die Logs aus Anwendungsprotokollen und Systemmeldungen mit einer Vielzahl an Fehlerquellen bestehen. Die typische Behebung einer Pipeline besteht aus mehreren Iterationen und Kontextwechseln. Aufgrund der Komplexität und der unstrukturierten Natur der Protokolle ist dies ein idealer Bereich, in dem generative KI die Arbeit beschleunigen kann. Durch den Einsatz von KI können Fehler in einer Pipeline signifikant schneller erkannt und behoben werden. Außerdem ist weniger Expertise für die Behebung einer Pipeline wie im obigen Beispiel erforderlich.Sieh dir die Ursachenanalyse von GitLab Duo in Aktion an:
Wie funktioniert die Ursachenanalyse?
Bei der Ursachenanalyse wird ein Teil des CI/CD-Stacktraces an ein GitLab-KI-Gateway weitergeleitet. GitLab stellt sicher, dass der weitergeleitete Teil in die Limitierungen des umfangreichen Sprachmodells (LLM) passt und erstellt einen vorgefertigten Prompt, um herauszufinden, warum der Job fehlgeschlagen sein könnte. Der Prompt weist das LLM außerdem an, ein Beispiel aufzuzeigen, wie ein(e) Benutzer(in) den fehlerhaften Job beheben könnte. Nachfolgend sind zwei Beispielszenarien, in denen die Ursachenanalyse hilfreich sein kann.
1. Analyse eines Abhängigkeitsfehlers in Python
Eine Python-Anwendung kann zusätzliche Bibliotheken mit Funktionen importieren, die nicht in der Standardbibliothek enthalten sind. Das Projekt Ursachenanalyse – Python-Konfiguration implementiert eine Anwendung, die die Konfiguration parst und eine SQLite-Datenbank initialisiert, wobei beide auch ohne zusätzlich installierte Abhängigkeiten funktionieren. Das Beispiel verwendet Best Practices in CI/CD mit einer Python-Umgebung sowie Cashing. Zuletzt wurde nun ein Redis-Caching-Client hinzugefügt, und jetzt schlägt der CI/CD-Build aus irgendeinem Grund fehl.
Durch die Ursachenanalyse erfährst du sofort, dass ModuleNotFoundError bedeutet, dass das Modul tatsächlich nicht in der Python-Umgebung installiert ist. GitLab Duo schlägt außerdem einen Fix vor: Installiere das Redis-Modul über den PIP-Paketmanager.
Die fehlerhafte Pipeline kann hier eingesehen werden.
Das Ergebnis der Ursachenanalyse gibt eine Zusammenfassung des Problems aus, das offensichtlich ein Fehler mit einem fehlenden redis-Modul ist. Versuchen wir nun, das Problem zu beheben, indem das redis-Modul installiert wird. Du kannst entweder pip install redis im Abschnitt script des CI/CD-Jobs aufrufen oder einen generellen Weg über die Datei requirements.txt wählen. Letztere ist nützlich für eine Single Source of Truth (einzige Quelle der Wahrheit) für Abhängigkeiten, die in der Entwicklungsumgebung und in CI/CD-Pipelines installiert wurden.
test:
extends: [.python-req]
stage: test
before_script:
# [🦊] hint: Root cause analysis. # Solution 1: Install redis using pip
- pip install redis
# Solution 2: Add redis to requirements.txt, use pip
- pip install -r requirements.txt
script:
- python src/main.py
Nachdem du die fehlende Python-Abhängigkeit behoben hast, schlägt der CI/CD-Job erneut fehl. Führe erneut eine Ursachenanalyse durch, um zu erfahren, dass kein Redis-Service den Job ausführt. Wechsle zum GitLab Duo Chat und gib den Prompt How to start a Redis service in CI/CD ein, um zu erfahren, wie du das Attribut services im CI/CD-Job konfigurierst.
Ändere .gitlab-ci.yml mit dem Job test und gib unter service den Dienst redis an.
test:
extends: [.python-req]
stage: test
before_script:
# [🦊] hint: Root cause analysis.
# Solution 1: Install redis using pip
- pip install redis
# Solution 2: Add redis to requirements.txt, use pip
- pip install -r requirements.txt
script:
- python src/main.py
# Solution 3 - Running Redis
services:
- redis
Wenn der Redis-Server ausgeführt wird, kannst du die Python-Anwendung erfolgreich ausführen und die Ausgabe im CI/CD-Log sehen.
Die Lösung kann auch im Unterordner in /solution eingesehen werden.
Tipp: Du kannst den GitLab Duo Chat auch bitten, zukünftige Probleme zu verfolgen:
How to lint Python code? Which tools are recommended for CI/CD.
How to pin a package version in Python requirements file?
What are possible ways that this exception stacktrace is triggered in the future?
Are there ways to prevent the application from failing?
Das nächste Beispiel ist fortgeschrittener und umfasst mehrere Probleme.
2. Fehlende Go-Laufzeit analysieren
CI/CD-Jobs können in Containern ausgeführt werden, die über das Attribut image konfiguriert werden. Wenn der Container keine Programmiersprachen-Laufzeit bereitstellt, schlagen die ausgeführten Kommandos in script, die auf die Binärdatei go referenzieren, fehl. Beispielsweise muss dann die Fehlermeldung /bin/sh: eval: line 149: go: not found verstanden und behoben werden.
Wenn der Befehl go nicht im Laufzeit Kontext des Containers gefunden wird, kann dies mehrere Gründe haben:
- Der Job verwendet ein minimales Container-Image, z. B.
alpine, und die Go-Laufzeit wurde nicht installiert. - Der Job verwendet das falsche Standard-Container-Image, z. B. das oben in der CI/CD-Konfiguration angegebene oder das Schlüsselwort
default. - Der Job verwendet kein Container-Image, sondern den Shell Executor. Auf dem Host-Betriebssystem ist die Go-Laufzeit nicht installiert oder ist anderweitig defekt/nicht konfiguriert.
Das Projekt Ursachenanalyse – Go GitLab Release Fetcher bietet ein Übungsprojekt zur Analyse und Behebung von CI/CD-Problemen mit einer in Go geschriebenen GitLab-Release-Fetcher-Anwendung. Die CI/CD-Jobs build und docker-build schlagen fehl. Für die Behebung des Problems sind verschiedene Voraussetzungen erforderlich: Du musst verstehen, warum die Go-Laufzeit nicht installiert ist, und etwas über die Syntax Dockerfile erfahren.
Das solution/-Verzeichnis bietet nach der Ursachenanalyse zwei mögliche Lösungen.
Probiere die Ursachenanalyse aus
Die folgenden Szenarien kannst du verwenden, um die Ursachenanalyse auszuprobieren.
-
Wenn du auf Kubernetes-Bereitstellungsfehler oder Zeitüberschreitungen stößt.
-
Wenn OpenTofu- oder Terraform-IAC-Pipelines die Cloud-Ressourcen nicht bereitstellen können.
-
Wenn das Ansible-Playbook mit einem kryptischen Berechtigungsfehler in CI/CD fehlschlägt.
-
Wenn der Java Stacktracer 10 Seiten lang ist.
-
Mit einem Shell-Skript, das einen Ausführungsfehler provoziert.
-
Wenn ein Perl-Skript in einer Zeile fehlschlägt, die die einzige Zeile im Skript ist.
-
Wenn der CI/CD-Job eine Zeitüberschreitung aufweist und nicht klar ist, welcher Abschnitt diese verursacht.
-
Wenn eine Zeitüberschreitung der Netzwerkverbindung erreicht wird und du denkst, dass es kein DNS sein kann.
Wie geht es mit der Ursachenanalyse von GitLab Duo in Zukunft weiter?
Wir wollen unseren Nutzer(inne)n langfristig helfen, ihre Pipelines in weniger Iterationen und schneller zu reparieren. Die Ursachenanalyse wird dabei in GitLab Duo Chat, unserem KI Assistenten, geöffnet und zeigt die Antwort dort. Benutzer(innen) können die Empfehlung dann direkt verwenden oder weiter mit dem Chat agieren, indem sie spezifische, weiterführende Fragen stellen (z. B. spezifische Fixes für eine bestimmte Programmiersprache) oder indem sie je nach Ursache nach alternativen Lösungen fragen.
Zum Beispiel ist hier die Ursachenanalyse für einen fehlgeschlagenen Job:
Benutzer(innen) können Folgefragen stellen, die auf der von der KI generierten Antwort basieren.
-
Ich möchte kein eigenes Docker Image erstellen. Bitte erkläre mir andere Möglichkeiten, das Problem zu beheben.
-
Ich habe keinen Zugriff auf die Docker-Image-Erstellung. Es sieht so aus, als würde die Go-Binärdatei fehlen. Gibt es alternative Images, die du vorschlagen kannst?
GitLab führt außerdem Qualitäts-Vergleiche für die erstellten Antworten durch, um das Nutzererlebnis langfristig zu verbessern.
Weitere Informationen findest du in unserem Epic zur Ursachenanalyse. Wir würden uns auch über dein Feedback zu dieser Funktionalität freuen. Bitte hinterlasst dafür einen Kommentar in unserem Feedback-Ticket zur Ursachenanalyse.
Erste Schritte mit der Ursachenanalyse
In unserer Dokumentation findest du Informationen dazu, wie du die Funktion als GitLab-Ultimate-Kund(inn)en aktivieren kannst. Außerdem ist die Ursachenanalyse von GitLab Duo bald in GitLab Self-Managed und GitLab Dedicated verfügbar.
Bist du kein(e) GitLab-Ultimate-Kunde/Kundin? Starte jetzt deine 30-tägige kostenlose Testversion.
