Get the MOST

Heute wurde der erste Release Candidate für Zikula Core 3.0.0 veröffentlicht.

Einen grundlegenden Überblick über die wichtigsten Änderungen sowie die weiterführenden Links zur Dokumentation und zu den Downloads sind dem Release-Artikel auf der Zikula-Website zu entnehmen: Zikula Core 3.0.0 Release Candidate 1 steht zum Testen bereit!.

Was bringt die neue Version?

Über einige der zahlreichen Neuerungen habe ich hier bereits in früheren Artikeln berichtet. Daher beschränke ich mich in diesem Beitrag darauf, die wichtigsten Links zum Nachlesen noch einmal gebündelt bereit zu stellen:

Mehrere Jahre lang hatten wir Trello verwendet und waren damit auch gut gefahren. Und mit der Zeit gewöhnt man sich auch an kleine Einschränkungen und lernt, diese mit eigenen Workflows zu umschiffen oder zu kompensieren. Dennoch hat es sich seit einigen Wochen nicht mehr rund angefühlt. Daher haben wir mehr als fünfzig verschiedene Tools angeschaut und für unsere Bedürfnisse als sehr sehr kleines Team verglichen. Darunter waren vorwiegend leichtgewichtige Kanban-orientierte Werkzeuge; die größeren Angebote, bei denen die eigentliche Arbeit wieder in einem Sumpf von Menüs verschwindet, waren hingegen schnell aussortiert. Der Gewinner für uns ist: MeisterTask 🏆 (dies ist ein Affiliate-Link!) In diesem Beitrag stellen wir kurz vor, was wir daran - im Vergleich zu Trello - besser und was weniger gut finden.

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.