Migrationen für Administratoren #

Diese Seite ist für Administratoren, die die Staging- oder Produktionsinstallation einer Site betreiben und die Migrationen anwenden, die Entwickler geschrieben haben. Sie schreiben keine Migrationen; Sie prüfen, was wartet, führen es zur richtigen Zeit aus und wissen, was zu tun ist, wenn ein Lauf scheitert. Alles hier geht in Setup > Migrationen oder auf der Konsole des Servers.

Was eine Migration für Sie ist #

Die Änderung eines Entwicklers an der Site (eine neue Tabelle, eine Inhaltsklasse, Inhalte, eine Rolle, eine Einstellung) kommt mit dem Code als Datei in migrations/. Die Installation merkt sich, welche sie angewendet hat. Eine ausstehende Migration ist eine, die diese Installation noch nicht angewendet hat. Sie anzuwenden ist ein Lauf: davor wird ein Sicherungspunkt genommen (ein Backup der Datenbank, der Dateien in var/ und der Einstellungen); geht etwas schief, wird der Sicherungspunkt automatisch zurückgespielt.

Den Stand lesen #

nicht nötig heißt, die Migration ist nicht für diese Umgebung oder diese Datenbank; das ist in Ordnung. Die Upgrade-Schritte des Kernels stehen zuerst, als Migrationen der Quelle kernel.

Die Routine um eine Auslieferung #

Vorher:

1. Lesen Sie den Stand: was steht aus, und braucht ein gescheiterter Lauf zuerst Aufmerksamkeit?
2. Öffnen Sie den Probelauf: jede ausstehende Migration mit dem, was sie ändern wird. Lesen Sie ihn; fragen Sie den Entwickler nach allem, was Sie nicht erwartet haben.
3. Klären Sie, ob eine Migration den Wartungsmodus einschaltet; planen Sie die Zeit.

Der Lauf:

4. Wenn der neue Code da ist, drücken Sie im Stand N ausstehende ausführen (oder führen Sie ./console exp:migration:migrate --apply aus). Lassen Sie die Kästchen, wie sie sind: die Voreinstellungen sind die sicheren.
5. Bestätigen Sie „Identität bestätigen“. Der Lauf startet im Hintergrund, und seine Seite öffnet sich; Sie können die Seite schließen, der Lauf geht weiter.

Nachher:

6. Die Seite des Laufs zeigt erledigt. Der Stand zeigt nichts Ausstehendes.
7. Sehen Sie auf der Site nach, wo sich die Änderung zeigt (ein neuer Bereich, ein neues Feld im Editor).
8. Der Entwickler bittet eventuell um eine Auslieferung der Caches; auf der Konsole ist das ./console exp:velocity deploy.

Wenn ein Lauf scheitert #

Sie sehen fehlgeschlagen auf der Seite des Laufs und im Dashboard-Block. Bis dahin ist automatisch geschehen:

• die gescheiterte Migration wurde angehalten, die nach ihr wurden nicht ausgeführt;
• ihre Datenbanktransaktion wurde zurückgerollt, so weit die Datenbank es kann;
• der gescheiterte Zustand wurde für den Entwickler in einem Sicherungspunkt bewahrt;
• der Sicherungspunkt von vor dem Lauf wurde wiederhergestellt: die Site ist so wie vor dem Lauf.

Was Sie tun: schicken Sie dem Entwickler die ID des Laufs und die Meldung auf seiner Seite (auch in seinem Protokoll). Führen Sie ihn nicht erneut aus, bevor der Entwickler die Migration korrigiert hat; dann nehmen Sie Fortsetzen. Rufen Sie den Entwickler sofort, wenn die Seite sagt, dass die Wiederherstellung gescheitert ist oder kein Sicherungspunkt genommen wurde: dann kann die Site halb geändert sein.

Zurücknehmen #

Setup > Migrationen > Rücknahme nimmt zurück:

Zuerst wird ein Sicherungspunkt des jetzigen Zustands genommen, sodass sich eine Rücknahme selbst zurücknehmen lässt. Die Wiederherstellung der Datenbank bringt alles auf den damaligen Stand zurück, auch was Redakteure seither veröffentlicht haben: stimmen Sie das vorher mit den Redakteuren ab.

Wer was darf #

In einer neuen Installation hat sie nur die Rolle Administrator. Geben Sie migration/read allen, die den Stand sehen sollen, und lassen Sie migration/run und migration/rollback auf Produktion bei den wenigen, die Änderungen anwenden.

Die Sperre #

Nur ein Lauf, eine Rücknahme oder ein Upgrade schreibt gleichzeitig. Ist einer im Gang, sagt die Seite Die Installation ist gesperrt und wer die Sperre hält; warten Sie. Eine Sperre eines beendeten Prozesses übernimmt der nächste Lauf; Sie löschen nie eine Sperrdatei.

Checkliste #

• To do: Der Dashboard-Block zeigt vor einer Auslieferung nichts Fehlgeschlagenes.
• To do: Der Probelauf wurde gelesen, und jede Zeile ergibt Sinn.
• To do: Wartungsfenster sind abgestimmt für Migrationen, die den Wartungsmodus einschalten.
• To do: Der Lauf wurde mit den voreingestellten Kästchen gestartet.
• To do: Nach dem Lauf: nichts ausstehend, der Push ist durchgegangen, die Site zeigt die Änderung.
• To do: Bei einem Fehler: ID und Meldung des Laufs gingen an den Entwickler; nichts wurde von Hand erneut ausgeführt.

Wie es weitergeht #

• Migrationen in der Administration
• Stand und Verlauf, Ausführen, Probelauf und Rücknahme
• Wenn eine Migration scheitert
• 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
• Ein Rundgang durch die Administration
• „Identität bestätigen“, Wartungsmodus
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.