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.
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.
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.
Hintergrund ist unter anderem, dass Themes ebenso wie Module eigenständige Symfony-Bundles sind und mehr als nur Layout können.
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.
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.
Seit kurzem haben neue Funktionen in die Template-Engine Twig Einzug gehalten. Diese verändern die Art und Weise, wie mit mehrwertigen Daten umgegangen wird, fundamental. Aus diesem Grund soll dieser Artikel beleuchten, wie man mit den neuen Möglichkeiten umgehen kann.
Was heißt deklarativ? Bei “filter, map und reduce” handelt es sich um ein Muster (Pattern) aus der funktionalen Programmierung. Es erlaubt die Veränderung von Sequenzen (Listen, Arrays, Vektoren, usw.) mittels mehrerer Operationen und Manipulationen, an deren Ende ein Ergebnis steht, welches entweder ausgegeben oder weiter verwendet werden kann.
Schon seit einiger Zeit hatte ich den Wunsch, eine Symfony-Gruppe zu besuchen, um dort einmal kurz zu zeigen, wie wir mit Symfony arbeiten. Gestern hatte es schließlich geklappt. In einem sehr angenehmen und lockeren Ambiente durfte ich mit meinem Talk “Maßgeschneiderte Bundles vom Fließband” zunächst Zikula als ein auf Symfony, Doctrine und Twig aufsetzendes Application Framework vorstellen. Anschließend habe ich dann einen Einblick in die modellgetriebene Entwicklung mit ModuleStudio und die mit der Code-Generierung einhergehenden Besonderheiten gegeben.
Der Zikula Core ist soeben in der Version 2.0.13 erschienen, da eine Reihe von sicherheitsbezogenen Änderungen in Symfony eingeflossen sind. Hier der Link zu den einzelnen Änderungen:
Changelog für 2.0.13 Auch wenn die Lücken die Standardinstallationen bzw. -nutzungen von Zikula offenbar nicht direkt betreffen, ist eine Einspielung des Updates natürlich dennoch empfehlenswert.
Weitere Informationen zu den einzelnen Patches können übrigens im Symfony-Blog nachgelesen werden.
