Get the MOST

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:

Eine Aktion zur PHP-Einrichtung

Für die wichtigsten Punkte, die notwendig sind, um ein auf PHP basierendes Projekt zu testen, gibt es die Action setup-php. Diese bietet unter anderem folgende Möglichkeiten:

• unterschiedliche PHP-Versionen verwenden
• PHP-Extensions einrichten
• PHP-Konfigurationen vornehmen
• zusätzliche, häufig verwendete Tools installieren

Diese Aktion sollte für allgemeine Anwendungen keine Wünsche offen lassen. Wir verwenden diese Aktion seit einigen Monaten in mehreren Repositories ohne jegliche Probleme.

Weitergehende Möglichkeiten

Auch Matrix-Builds sind möglich: hiermit lässt sich ein Workflow für mehrere Betriebssysteme und/oder PHP-Versionen ausführen.

Nach der allgemeinen Einführung in GitHub Actions kommen wir nun zu dem ersten Anwendungsfall, der in vielen Projekten angewendet werden kann. Fast jedes Softwareprojekt bedient sich heutzutage zusätzlicher Drittkomponenten. Diese müssen regelmäßig geprüft und auf Stand gehalten werden, um sowohl Fehlerkorrekturen als auch neue Funktionen zu erhalten. In den meisten Programmiersprachen und Umgebungen kommen Paketmanager zum Einsatz, mit denen diese Abhängigkeiten verwaltet und gepflegt werden. Das ist eine geeignete Voraussetzung dafür, die Updates zu automatisieren.

Mit GitHub Actions ist es möglich, beliebige Workflows in einem GitHub Repository zu definieren und dort auch automatisch ausführen zu lassen. Das können Builds und Tests zur kontinuierlichen Integration sein, aber auch völlig unabhängige Prozesse, zum Beispiel zur regelmäßigen Prüfung bestimmter Anforderungen.

In den letzten Wochen und Monaten haben wir mehrere Dutzend Workflows mit GitHub Actions abgebildet und entsprechende Erfahrungen gesammelt. Im Rahmen einer kleinen Artikelserie werden wir einige der vielfältigen Möglichkeiten vorstellen, die sich mit GitHub Actions auftun.

Schon seit einiger Zeit werden im GitHub-Repository des Zikula Core die Dinge dokumentiert, die zusätzlich zu den Handbüchern von Symfony, Doctrine, Twig, Bootstrap usw. zu beachten sind. Nun wurde die Struktur dieser Dokumente jedoch überarbeitet und in eine Gesamtsicht gekleidet.

Themenorientiert

Frühere Ansätze von Handbüchern und Doku-Sammlungen haben oft versucht, unterschiedliche Bereiche für Entwickler und Administratoren aufzubauen. Dies hatten wir wieder versucht, sind dann aber zu der Erkenntnis gelangt, dass es zu viele Überschneidungen gibt und das Ganze vor allem unübersichtlich wird.

Nachdem wir bereits in einigen Artikeln zu Zikula 3 die Änderungen unter der Haube, umfangreiche Modernisierungen, Möglichkeiten für dynamische Formulare und Neuerungen rund um Übersetzungen vorgestellt hatten, sollen nun einige weitere der neuen Features und Änderungen vorgestellt werden.

Module + Themes = Extensions

Die Verwaltung von Modulen und Themes läuft nun unter einem gemeinsamen Dach: Extensions.

Nachdem zwischen den Jahren der komplette Unterbau von Zikula 3 auf Stand gebracht worden ist, hat sich der nächste Sprint dem Übersetzungssystem gewidmet. In diesem Beitrag wird kurz dargestellt, welche neuen Funktionen eingebracht worden sind:

• Es gibt eine verbesserte Unterstützung für Regionen und Sprachvarianten (z. B. de_DE und de_CH neben de).
• Die automatische Erkennung zusätzlich vorhandener Sprachpakete wurde verbessert.
• Die Konfiguration für die Übersetzung von Modulen und Themes wird automatisch auf Stand gehalten.
• Mit der Funktion “Edit in Place” können Übersetzungen direkt auf einer Seite via Mausklick bearbeitet und gespeichert werden.
• Eine direkt im System verfügbare Weboberfläche erlaubt das Anlegen, Bearbeiten und Entfernen von Übersetzungen für das Kernsystem sowie vorhandene Module und Themes.
• Auch für Entwickler gibt es neue Vorteile: viele Dinge werden nun automatisch übersetzt, wie etwa Labels, Auswahloptionen und Hilfetexte für Formularfelder, Flash-Nachrichten oder Labels und Linktitel für Einträge in Knp-Menüs. Es muß kein Translator-Objekt mehr injiziert und verwendet werden. Auch beim Extrahieren der Übersetzungskataloge werden diese Nachrichten automatisch mit übernommen.

Im Rahmen des letzten Sprints wurde der Unterbau von Zikula 3 auf den neuesten technischen Stand gebracht. Im Folgenden wird kurz zusammengefasst, was hierbei genau passiert ist.

Twig 3

Als erstes sollte die Template-Engine Twig auf die Version 3 gebracht werden. Dies versprach anfangs eine sehr übersichtliche Sache zu werden. Allerdings gab es dann doch noch einige weitere Aspekte zu beachten:

• Da die templating-Komponente in Symfony 5 entfernt wird, müssen Pfade zu Templates nun der Namespace-Notation folgen. Aus z. B. Bundle:Controller:Action.html.twig wird damit @Bundle/Controller/Action.html.twig.
• Bedingungen in Schleifen sollten zur neuen filter-Syntax umgeschrieben werden.
• Die früheren Twig Extensions werden durch neue Twig Core Extra Extensions abgelöst.

Alle wichtigen Änderungen haben wir in einem Dokument zusammengefasst.