Build Warnung bei Dependency Updates
Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus.
Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden.
Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.
Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.
Die Bausteine sind dabei simpel:
-
GitLab CI als Buildserver (hier kann aber auch jeder andere Buildserver verwendet werden)
-
Das Maven
versions-Plugin, um Abhängigkeiten auf Updates zu prüfen -
Ein Build-Job, der das Ergebnis der Prüfung visualisiert
-
Regelmäßige Ausführung der Pipeline
Vorweg: Nur, weil es potentielle Updates gibt, sollte der Build natürlich nicht abbrechen.
Dazu wird bei GitLab-CI für den jeweiligen Prüfschnritt das Property allow_failure auf true gesetzt.
Zur Prüfung auf Updates gibt es bei Maven das versions-Plugin mit den Goals display-dependency-updates und display-property-updates.
Ersteres wird verwendet, wenn die Versionen direkt an den Dependencies im pom.xml konfiguriert sind.
Werden in der Maven Konfiguration Properties verwendet, um bspw. an zentraler Stelle oder für mehrere zusammengehörige Libraries die Versionen zu pflegen, kann display-property-updates die Prüfung durchführen.
check-property-updates:
stage: build
image: maven:3-jdk-11
allow_failure: true
script:
- mvn versions:display-property-updates -Dversions.outputFile=version-report.txt
- if grep 'The following version property updates are available' version-report.txt >> /dev/null; then cat version-report.txt; false; else true; fi
only:
- masterDa die Pipeline nicht abbricht, wenn dieser Job fehlschlägt, kann das Artefakt weiterhin erfolgreich getestet und gebaut werden. In der Pipelineansicht wird für Entwickler jedoch sofort transparent, dass es etwas zu tun gibt.
Die Ausgabe des Jobs kann über die GitLab Oberfläche abgerufen werden, und es ist auch ersichtlich, welche Abhängigkeiten zu aktualisieren sind.
Im folgenden Beispiel ist die Jib Version nicht mehr aktuell.
Damit die Pipeline schnelles Feedback liefert und nicht nur für Projekte, an denen aktiv entwickelt wird, bietet sich eine nächtliche Ausführung an. GitLab CI bietet dazu die Schedules an.
Im Laufe der Zeit wechseln sich typischerweise erfolgreiche Builds ohne jegliche Fehler (grün), fehlgeschlagene Builds durch Testfehler oder Compilefehler (rot) und erfolgreiche Builds mit Warnungn (orange) ab.
Eine weitere Ausbaustufe, die mit einem analogen Ansatz erfolgen könnte, ist die Prüfung auf bekannte Sicherheitsprobleme.
Dazu gibt es beispielsweise von OWASP das dependency-check-maven Plugin.
Ebenfalls denkbar sind andere Prüfungen, wie Performance-Regressions oder verwendete Docker Images.
Zu den Themen Spring Boot, Spring Framework und Java bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.