Migrationen in Kundenprojekten #

Diese Seite ist für Agenturen und Integratoren, die Exponential-Sites für Kunden bauen und betreiben. Seit 6.0.15 können die Änderungen, die Sie an Datenbank, Inhalten und Einstellungen eines Kunden vornehmen, als Migrationen reisen: einmal geschrieben, auf Ihrer Entwicklungskopie getestet, auf Staging und Produktion des Kunden in derselben Reihenfolge angewendet und in Git aufgezeichnet, wo der Kunde sie sehen kann.

Was sich für Ihre Projekte ändert #

Zwei Orte für eine Migration #

./console exp:migration:generate --skeleton news_archive_folder --apply
./console exp:migration:generate --skeleton widget_table --source=extension:acmewidgets --apply

Die Migrationen einer Erweiterung werden nur gefunden, solange die Erweiterung aktiv ist. Eine Migration der Site, die auf einer aufbaut, nennt sie im Kopf: requires: 20261101090000_widget_table oder requires: extension:acmewidgets. Braucht jede Installation der Erweiterung die Änderung beim Upgrade, ob eine Site sie gewählt hat oder nicht, liefern Sie stattdessen einen Upgrade-Schritt aus (Upgrade-Schritt oder Migration?).

Umgebungen je Kunde #

Jede Installation nennt ihre Umgebung in site.ini [AdminEnvironment] Level (development, test, staging, production oder auto mit EXP_ENV). Ein Migrationskopf kann eine Migration einschränken:

// environments: staging, production
// environments: !development

Startdaten für Ihre Entwicklungskopien, Testbenutzer, Demo-Inhalte: geben Sie diesen Migrationen environments: development. Migrationen je Umgebung erklärt die Einzelheiten.

Importe über die Remote-ID #

Kunden-Sites unterscheiden sich in ihren Objekt- und Knoten-IDs. Finden Sie alles über Remote-ID oder Bezeichner, und geben Sie allem, was eine Migration anlegt, eine eigene Remote-ID (acme-news-folder). Dieselbe Regel macht Importe wiederholbar: Idempotente Importe über die Remote-ID. Eine so geschriebene Migration läuft auf der Installation jedes Kunden und verträgt nach einem Fehler einen halb erledigten Zustand.

Übergabe #

Nach jedem Lauf werden Statusdatei und Laufprotokoll committet, als migrations/<umgebung>/<run-id> getaggt und gepusht. Bei der Übergabe bekommt der Kunde im Repository, das ihm gehört:

• migrations/: jede Änderung, mit Beschreibung und Autor im Kopf;
• migrations/status/<umgebung>.json: was jede Umgebung angewendet hat;
• migrations/runs/: das Protokoll jedes Laufs;
• die Tags: einer je Lauf, nie verschoben.

Setzen Sie [RepositorySettings] Remote auf das Repository des Kunden und geben Sie dem Systembenutzer jeder Installation die Push-Zugangsdaten (einen Deploy-Schlüssel). Übergeben Sie die Richtlinien: wer in der Administration des Kunden migration/run und migration/rollback hat (Richtlinien, Ansichten und Ereignisse).

Aufwand schätzen #

Checkliste für Kundenprojekte #

• To do: Die Aufzeichnungstabellen gibt es auf jeder Umgebung (6.0.15-migration-tables ist in exp:upgrade:status done).
• To do: Jede Installation nennt ihre Umgebung; RunAsUser ist der Login eines vorhandenen Administrators.
• To do: git_manager ist aktiv, und das Remote nimmt Pushes von jeder Installation an; migrationpush ist geplant.
• To do: Die CI führt ./console exp:migration:check bei jedem Pull Request aus.
• To do: Jede Migration findet Dinge über Remote-ID oder Bezeichner und sagt, wie sie zurückgenommen wird.
• To do: Richtlinien: nur wer auf Produktion Migrationen ausführen soll, hat migration/run.
• To do: Plattenplatz für Sicherungspunkte ist mit dem Hoster abgestimmt.

Livegang #

1. Frieren Sie die Migrationen ein, die live gehen; exp:migration:check besteht.
2. Auf Staging, aus einer Kopie der Produktion wiederhergestellt: exp:migration:migrate, dann --apply; prüfen Sie die Site.
3. Auf Produktion: den Code ausliefern, ./console exp:migration:migrate --apply, die Caches ausliefern (Mit Migrationen ausliefern).
4. ./console exp:migration:status --fail-on-pending endet mit 0; der Push ist durchgegangen.
5. Nehmen Sie den Tag des Laufs in die Release-Notizen für den Kunden auf.

Die ganze Site eines Kunden von einem anderen System oder einem anderen Hoster umzuziehen, ist keine Migration in diesem Sinn: Migrationen oder Umzug einer Site.

Wie es weitergeht #

• Migrationen in einer Erweiterung oder einem Paket
• Teamarbeit mit Git
• Tags pushen
• Jetzt beginnen: das Tutorial

Verwandte Seiten #

• Migrationen: der Einstieg
• Migrationen: die Anleitung
• Migrationen: das Tutorial
• PHP-Migrationen
• Migrationen in der Administration
• Die Migrationsbefehle
• Die Migrationseinstellungen
• Das Migrationsdateiformat
• Wenn eine Migration scheitert
• Fehlerbehebung bei Migrationen
• Migrationen oder Umzug einer Site
• Integratoren: hier beginnen
• Eine Integration als Erweiterung bauen, Übergabe einer Integration, Integrationsaufwand schätzen, Checkliste für den Livegang einer Integration
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.