Dependabot: Dependency-Management im Überblick
Der Code wurde verfasst, in GitLab gepusht, von einem oder mehreren Reviewern abgesegnet und in den master gemergt. Beruhigt kann also der feature-Branch gelöscht werden und der Entwickler kann sich mit weiteren „Customer requirements“ beschäftigen.
Was passiert aber, wenn es Updates von verwendeten Dependencies gibt? Klar, könnte man diese in den neuen Branches berücksichtigen. Das bedeutet aber, dass der Entwickler evtl. manuell die Updates prüfen und entsprechend im Dependency-Manifest verwalten müsste. Der größte Nachteil an diesem Vorgehen ist das Stichwort „manuell“.
Diese Arbeit soll vom sog. Dependabot abgenommen werden. Ein weiteres Indiz also, dass menschliche Arbeit zunehmend durch Bots ersetzt werden soll (hier aber im positiven Aspekt).
Dependabot wurde von der gleichnamigen Firma entwickelt und gehört seit 2019 zu GitHub. Eine Integration zu GitLab ist dennoch möglich. Eine Einleitung hierfür ist unter https://bobbybouwmann.nl/blog/dependabot-on-gitlab verfügbar.
Dependabot sucht im Repo nach den Manifest-Dateien (pom.xml, package.json, Dockerfile, …) und gleicht die eingetragenen Versionen der Dependecies mit den verfügbaren Versionen im entsprechenden GitHub Repository oder in anderen öffentlichen Registries (Maven Central, npm-Registry, Docker Hub) ab. Dabei crawlt Dependabot nicht das ganze Repo, sondern identifiziert die Art der Paketverwaltung (maven, gradle, npm, yarn, docker) und die Location der Manifest-Dateien über Umgebungsvariablen im GitLab-Repository. Eine Auflistung der erforderlichen und optionalen Variablen ist unten zu finden. Wurde eine aktuellere Version gefunden, wird über die GitLab API ein Merge Request ausgelöst.
| Variablen | Bedeutung | Erforderlich |
| GITLAB_ACCESS_TOKEN | Persönlicher GitLab Access Token für die GitLab API |
X |
| GITHUB_ACCESS_TOKEN | Persönlicher GitHub Access Token für die GitHub API (nicht erforderlich, aber empfehlenswert) |
– |
| GITLAB_HOSTNAME | GitLab Host (gitlab.com oder internes GitLab) |
X |
| PROJECT_PATH | Relativer Pfad zum prüfenden Repository |
X |
| PACKAGE_MANAGER_SET | Art der Packerverwaltung (maven, npm, yarn, docker) |
X |
| DIRECTORY_PATH | Relativer Pfad zur Mainfest-Datei (default ist root) |
Im Nachfolgenden die Vor- und Nachteile dieses Tools im Überblick.
| Vorteil | Nachteil |
| Automatische Generierung von Merge Requests | GitHub Token ebenfalls notwendig, da über die GitHub API Versionen der Dependencies geprüft werden |
| Unterstützung von vielen Plattformen:
· Ruby · JavaScript · Java (Maven und Gradle) · Docker · Python · PHP · … |
Keine rekursive Durchsuchung von Manifest-Dateien im Repository |
| Private Docker-Registries werden grundlegend unterstützt | Eine Integration zur Harbor-Registry konnte im ersten Anlauf nicht erzielt werden |
| Keine funktionelle Änderung des Projektes erforderlich |
Ausblick
Interessant wäre der Einsatz von Dependabot in privaten Registries, wie Harbor oder Nexus, damit das Tool flächenübergreifend für interne Kundenprojekte genutzt werden kann. Alternativ ist hier auch ein eigenes Tool denkbar, das auf die interne Infrastruktur zugeschnitten ist. Eine weitere Alternative wäre Renovate. Die Integration dieses Tools konnte jedoch nicht verifiziert werden, da das GitLab-Repository nicht identifiziert werden konnte.
Um nicht zur Thematik „Eigenentwicklung vs. Standartsoftware“ zu gelangen, möchte ich mit einem kurzen Fazit abschließen.
Fazit
Dependabot bietet eine sehr angenehme Möglichkeit Dependecy-Updates zu verwalten und im Projekt zu integrieren. Es entfällt dabei die manuelle Suche nach Updates. Durch das große Spektrum an unterstützten Plattformen kann das Tool sehr flexibel eingesetzt werden. Auch das Management von Updates unterschiedlicher Plattformen im selben Projekt, kann mittels Schedules realisiert werden. Es sollte jedoch die Integration von Dependabot oder ähnlichen Tools mit Besonderen Augenmerk auf firmeneigenen Registries im nächsten „Sprint“ weiter untersucht werden.
