Ibexa DXP v3.3 Feature Preview: Migrations-Bundle

Ein digitaler Service startet oft als Projekt. Wirklich lebendig wird er aber erst nach dem Launch durch die fortlaufende Wartung. Nach den anfänglichen Schritten geht die Arbeit weiter, da Funktionen hinzugefügt und Designs geändert werden. Während der Pre-Launch-Phase ist das Hinzufügen und Ändern relativ einfach, da das System noch nicht live ist. Nach Live-Gang erfordert das Durchführen von Änderungen mehr Disziplin, was aber nicht zu einer Verringerung des Entwicklungstempos führen muss. Mit Ibexa DXP 3.3 fügen wir ein Tool hinzu, das die Verwaltung von Änderungen erleichtert: Ibexa Migrations-Bundle.

Ibexa DXP verfügt über umfangreiche Tools zur Verwaltung von Änderungen an Inhalten und Daten, von der integrierten Versionierung bis hin zum Papierkorb und mehr. Entwickler sind schon lange daran gewöhnt, ihren Code so zu speichern, dass Änderungen nachverfolgt werden können. Diese Praxis wurde durch das Konzept von Infrastructure as Code (IaC) auf das Hosting ausgeweitet; die Servicekonfiguration wird zusammen mit der Anwendungslogik in der Versionskontrolle gespeichert. Die benötigte Infrastruktur wird automatisch auf der Grundlage dieser Blaupause bereitgestellt. So funktioniert Ibexa Cloud.

Änderungen an der Datenstruktur lassen sich auch mit Hilfe der Versionskontrolle nachverfolgen. Datenbankschema-Migrationen bedeuten, dass Änderungen an den Datenbankdefinitionen als Dateien gespeichert werden, die in anderen Umgebungen ausgeführt werden können, um Änderungen zu replizieren. Ibexa DXP verwendet zusammenhängende Datenbanken, um Rohdaten zu speichern. Datenbankmigrationen, um Änderungen in das Content Repository zu verschieben, sind jedoch nicht praktikabel.

Hier kommt "Ibexa Migrations" ins Spiel. Mit diesem Paket können Änderungen am Repository in Konfigurationsdateien definiert werden. Diese können an einer anderen Stelle ausgeführt werden und die Änderungen werden in der jeweiligen Umgebung vorgenommen. So kann ein Entwickler ein neues Feld auf seinem lokalen Rechner hinzufügen und eine definierte Datei erzeugen, die in das Staging und schließlich in die Produktion übertragen werden kann. Dies reduziert nicht nur die manuelle Arbeit, sondern auch mögliche menschliche Fehler.

Ein Überblick über Migrationen in der Entwicklung

Migrationen sind eine entwicklerorientierte Funktion, mit der Administratoren und Besucher nie direkt in Kontakt kommen werden. Um es verständlicher zu machen, betrachten wir im Folgenden eine einfache Funktionserweiterung. Es gibt eine Anfrage, ein Intro-Textfeld zu Blogbeiträgen hinzuzufügen und es über dem Textkörper anzuzeigen. Ohne die Verwendung von Migrationen müsste der Entwickler das Feld entweder manuell zu jeder Datenbank (Produktion, Staging und Entwicklung) oder es zur Produktionsdatenbank hinzufügen und es in die anderen Umgebungen kopieren. Darüber hinaus muss der Entwickler den Code manuell mit der verwendeten Datenbank synchron halten.

Das manuelle Kopieren der Felddefinitionen funktioniert zwar immer, ist aber mühsam und anfällig für Tippfehler. Änderungen in der Hauptdatenbank vorzunehmen und sie nach unten zu kopieren, ist möglich, hat aber einige Nachteile: Alle Daten werden in der Zieldatenbank zurückgesetzt, was möglicherweise nicht gewünscht ist. Zudem ist es aufwendig, die gesamte Datenmenge zu übertragen. Dies ist bei großen Datenbanken nicht machbar. Manchmal können Änderungen auch nicht in die Produktion übernommen werden (z. B. beim Erstellen eines benutzerdefinierten Feldtyps). Letztlich ist beides nicht ideal.

Mit Migrationen können wir die Änderungen in eine kompakte Migrationsdatei exportieren, die portabel ist. Wenn die Migration ausgeführt wird, werden die Änderungen an Ort und Stelle auf das Repository angewendet, ähnlich wie wenn es manuell über die Administrationsoberfläche erfolgen würde. Diese Datei wird auch mit der Code-Version gespeichert. In unserem Beispiel ist das die Änderung der Vorlage, die das Intro-Textfeld anzeigen würde. Dies bindet sowohl Logik- als auch Datenänderungen ein. Wenn diese Version bereitgestellt wird, wird das Feld hinzugefügt und der Code wird aktualisiert.

Ein kurzer Praxistest mit Ibexa-Migrations

Die Migrationsfunktionalität läuft vollständig als Kommandozeilen-Anwendung. Benutzer haben die Möglichkeit, Migrationsdateien auszuführen, zu generieren und zu konvertieren (mehr dazu weiter unten). Die Dateien selbst sind in lesbarem YAML und können manuell mit einem Texteditor erstellt werden. Das Markup zum Hinzufügen des Intro-Textfelds zum Beitrag wird unten gezeigt:

-
    type: content_type
    mode: update
    match:
        field: content_type_identifier
        value: blog_post
    metadata:
        identifier: blog_post
    fields:
        -
            identifier: intro_text
            type: ezrichtext
            position: 5
            translations:
                eng-GB:
                    name: Intro text
            required: true
            searchable: true
            infoCollector: false
            translatable: true

Abgelegt im Verzeichnis src/Migrations/Ibexa/, kann es mit der Konsole ausgeführt werden:

$ ./bin/console ibexa:migrations:migrate
Please specify migration file:
add_intro_to_blog_post.yaml
done!

Durch die Einbindung in die Versionskontrolle ist die Anwendung portabel und kann in jeder Umgebung leicht eingesetzt werden.

Migrationen sind ein Bestandteil der Infrastruktur

Die erste Version des Migrations-Bundle mit Ibexa DXP wird die Möglichkeit haben, mit Locations, Content und Content-Typen, Metadaten wie Objektstatus und Abschnitten sowie mit Anwendern und Benutzergruppen zu arbeiten. Dies deckt nicht alle möglichen Anwendungsfälle ab, jedoch die gängigsten. In Zukunft werden wir weitere Fähigkeiten hinzufügen, auch für neue Funktionen wie Segmente und die Segmentation API, die in Ibexa DXP 3.2 eingeführt wurde.

Es ist erwähnenswert, dass es einige Migrationspakete von Drittanbietern für Vorgängerversionen von Ibexa DXP gab. Mit der Version 3.3 fügen wir nun eine ähnliche Option zu unserem Produkt hinzu. Mit einer First-Party-Option können wir die volle Verantwortung für Wartung und Support übernehmen. Dank einer Clean-Sheet-Implementierung haben wir eine zeitgemäße Basis, die es uns ermöglicht, neue Funktionen, die wir unserem Repository hinzufügen, schnell zu unterstützen.

Kunden, die ein Upgrade auf Ibexa DXP 3.3 durchführen möchten und bereits eine Drittanbieter-Option wie das Kaliop Migrations Bundle verwenden, können Migrationsdateien in das Ibexa Migrations-Format konvertieren. Optionen von Drittanbietern werden weiterhin funktionieren, solange sie mit der Kernsoftware kompatibel sind. Allerdings werden sie nicht vom Produktsupport abgedeckt. Die empfohlene Lösung für die Produkte der Version Ibexa DXP 3.3 LTS (Ibexa Content, Ibexa Experience und Ibexa Commerce) ist die enthaltene Migrationsfunktionalität.

Migrationen sind letztlich ein Hilfsmittel, um die Entwicklung zu beschleunigen, ohne die Qualität zu beeinträchtigen. Man kann sie schrittweise einführen. Die Website ibexa.co zum Beispiel wurde ohne Migrationslösung entwickelt, wird aber in den kommenden Monaten Ibexa Migrations nutzen. Weitere praktische Blogbeiträge darüber, wie Ibexa DXP helfen kann, die Komplexität von Digital Experience Platform-Implementierungen zu bewältigen, werden folgen.

Photo by Richard Lee on Unsplash