Get the MOST

Um Dependencies aktuell zu halten, wird bei GitHub oft und gerne der Dependabot eingesetzt. Mit Renovate existiert allerdings eine äußerst flexible Alternative, die im Folgenden kurz vorgestellt wird.

Zu den wichtigsten Stärken von Renovate gehören folgende Eigenschaften:

• Updates können anhand vielfältiger Kriterien in gemeinsame Merge Requests gruppiert werden. Bei einem Symfony-Update muss man somit nicht mehr jede Symfony-Komponente einzeln aktualisieren und mergen.
• Bestimmte Updates können bei Bedarf automatisch eingespielt werden.
• Die Häufigkeit von Merge Requests kann ebenso eingestellt werden wie diverse Standardvorgaben, wie etwa die zuzuordnenden Bearbeiter, Reviewer oder Labels.
• Über eine Onboarding-Funktionalität können neue Repositories automatisch mit verarbeitet werden.
• Unterstützt über 60 verschiedene Paketierungsformate. Auch abweichende und individuelle Konventionen können konfiguriert werden.
• Eignet sich insgesamt perfekt für Monorepos.
• Ein Dashboard zeigt den Status aller Dependencies im Überblick.
• Es funktioniert auf mehreren Plattformen, so gibt es unter anderem Support für GitHub, GitLab und BitBucket.

Für den Einstieg und weiterführende Informationen ist ein Blick in die Doku zu empfehlen.

Mit dem Build-System Nx lassen sich beliebige Projekte in einem Monorepo auf einheitliche Weise testen und bauen. Es bedient sich verschiedener npm-Plugins, um dies für unterschiedliche Technologien umzusetzen. Ein Projekt kann dabei entweder als Applikation oder als Bibliothek abgebildet werden. Dies kann für ein Java-basiertes Projekt etwa durch Maven oder Gradle erfolgen.

Um ein einzelnes Projekt zu testen oder zu bauen, reicht ein Aufruf in der Form nx test <app> bzw. nx build <app>. Durch die Möglichkeit, dass Projekte Abhängigkeiten untereinander deklarieren können, kann dies auch transitiv geschehen. Nachdem ein Projekt gebaut worden ist, werden die Builds von abhängigen Projekten ebenfalls durchgeführt.

Vor knapp eineinhalb Jahren haben wir gezeigt, wie man die Aktualisierung verwendeter Drittkomponenten mit GitHub Actions automatisieren kann.

Zwischenzeitlich sind wir hierbei auf den Dependabot umgestiegen. Dieses Tool wird bei GitHub schon länger zum Aufspüren und Melden von Sicherheitsproblemen verwendet. Es ist damit jedoch auch möglich, Updates zu suchen und bereitzustellen.

Im Gegensatz zu dem früheren Vorgehen gibt es dabei folgende Unterschiede und Vorteile:

• Für jede Komponente wird ein eigener Pull Request erstellt. So lassen sich mögliche Probleme in den Builds unabhängig erkennen und die Updates lassen sich selektiv mergen.
• Die enthaltenen Commits sowie etwaige Release Notes und Changelogs werden direkt im Pull Request zur Verfügung gestellt, um die damit einhergehenden Änderungen transparent zu machen.
• Die Pull Requests werden bei Änderungen im Zielbranch automatisch via Rebase aktualisiert, um Merge-Konflikten vorzubeugen.
• Gibt es für eine Komponente eine neue Version, wird ein möglicherweise noch offener Pull Request mit einer früheren Version automatisch mit einem entsprechenden Kommentar (Superseded by #123) geschlossen.
• Wie im Screenshot zu sehen ist, kann man in Form von Kommentaren mit Dependabot interagieren und so das Verhalten steuern.
• Es gibt ein einheitliches Interface für unterschiedliche Arten von Paketmanagern. So werden nicht nur Composer, npm und yarn unterstützt, sondern zum Beispiel auch Maven, pip, Terraform und auch GitHub Actions.

Ein Beispiel

Mit der folgenden Konfiguration wird Dependabot die Aktualisierungen für PHP-Vendors (composer), JavaScript-Vendors (npm) und die in den CI-Builds verwendeten Komponenten (github-actions) übernehmen:

Hugo ist ein Generator für statische Seiten, welcher auf der Programmiersprache Go basiert. Die Inhalte werden mit Markdown verwaltet und dynamisch in HTML umgewandelt. Dies ist für die meisten kleineren Projekte interessant, weil ausreichend und im Vergleich zu einem dynamischen Content Management System einfacher zu handhaben; zudem sind statische Seiten auch in Bezug auf Sicherheit und Performanz unschlagbar (siehe auch: Vorteile statischer Seiten).

Der Build lässt sich dann z. B. mit GitHub Actions durchführen (zum Einsatz kommt hierfür z. B. diese Action), wobei die resultierende Seite direkt mit GitHub Pages betrieben werden kann. Wer den Komfort einer UI zur Pflege der Inhalte nicht missen möchte, kann ein entsprechendes Frontend obendrauf packen.

Zu den grundlegenden Aufgaben automatisierter Builds zählen unterschiedliche Prüfungen: so bietet es sich an, die Einhaltung der Coding-Styles zu überwachen, Qualitätsmetriken zu erheben und die Testabdeckung zu messen. Auch die regelmäßige Aktualisierung verwendeter Drittkomponenten kann perfekt automatisiert werden, wie wir es in diesem Beitrag für GitHub Actions gezeigt haben.

Ein nützliches Werkzeug, das anhand einer composer.lock Datei etwaige Sicherheitslücken in verwendeten Vendors aufgezeigt hatte, war der SensioLabs Security Checker. Dieser hat die entsprechenden Versionen mit einer Datenbank auf security.symfony.com abgeglichen und entsprechende Probleme gemeldet. Der entsprechende Datenbestand befindet sich ebenfalls auf GitHub.

Im offiziellen GitHub Changelog werden regelmäßig Beiträge über unterschiedliche Neuerungen und Innovationen auf der GitHub Plattform veröffentlicht, zum Beispiel in Bezug auf Funktionen in der Oberfläche, GitHub Actions oder anderweitige Aktivitäten. Gestern erschien dort ein Artikel darüber, dass nun die Funktionalität zum Scannen von Code auf Sicherheitsprobleme allgemein verfügbar gemacht worden ist. Weitere Informationen hierzu lassen sich diesem Beitrag entnehmen. Neben der von GitHub forcierten CodeQL Analyse stehen auch alternative Analysewerkzeuge von Drittanbietern zur Integration bereit.

Vor ein paar Wochen haben wir unsere generator-action vorgestellt, welche die einfache Generierung von Zikula-Erweiterungen mit dem Standalone Generator von ModuleStudio erlaubt. Diese Action wird als Docker Image bereitgestellt und kann auch losgelöst von GitHub Actions verwendet werden.

Die zikula-action

Analog dazu steht auch eine weitere GitHub Action zur Verfügung: die zikula-action. Dieses Docker Image basiert auf der ebenfalls bereits vorgestellten phpqa-Toolbox und hat somit Zugriff auf zahlreiche Tools rund um Analyse, Tests und Qualitätssicherung.

Der Standalone-Generator

ModuleStudio bietet einen Standalone-Generator, mit dem sich jederzeit eine Anwendung über die Kommandozeile generieren lässt. Einige allgemeine Informationen hierzu sind der Dokumentation zu entnehmen. Ein simples Beispiel für die Nutzung findet sich ferner in diesem Artikel.

Eine Besonderheit hierbei ist, dass die verwendete jar-Datei bei jedem Build des Generators aktualisiert wird. Es handelt sich also immer um den aktuellen Git-Stand. Damit bietet es sich an, den Standalone-Generator zur kontinuierlichen Integration zu verwenden.

In diesem Beitrag geht es darum, mehrere und unterschiedliche Build Jobs miteinander zu verknüpfen. Je größer eine Build Infrastruktur wird, desto häufiger wird man mit solchen Anforderungen konfrontiert, möchte man nicht einen riesigen Monolithen bauen.

Bei ModuleStudio gibt es beispielsweise mehrere Komponenten, die jeweils komplett unabhängig gebaut und getestet werden. Dennoch muß es für Integrationstests und zum Bauen der fertigen Produkte möglich sein, dass eine neue Version einer Komponente die Jobs für weitere Komponenten startet und somit eine Ausführung deren Workflows nach sich zieht.

Nachdem im letzten Artikel gezeigt wurde, mit welchen Mitteln sich in GitHub Actions Projekte auf Basis von PHP verarbeiten lassen, schauen wir nun auch einmal kurz in die Java-Welt.

Werkzeuge für das Build-Management

In Java ist es gang und gebe, die Builds mit spezifischen Tools zu beschreiben, hier sind als gängigste Beispiele Maven, Gradle oder auch Ant zu nennen. Das ist insoweit hilfreich, als dass viele Abhängigkeiten darüber verwaltet werden.

Das allgemeine Vorgehen für Java-Projekte sieht daher wie folgt aus: