Mit Git aktualisieren: synchron mit GitHub bleiben #

Ein Update einer Site aus Git-Klonen (Mit Git entwickeln) besteht immer aus zwei Schritten, in dieser Reihenfolge:

1. Git bringt den Kernel auf den neuesten Stand: Die neuen Commits von GitHub werden in den Branch Ihrer Site gemergt. Das ändert die Dateien des Kernels und mit ihnen composer.json, die Liste der Erweiterungen und ihrer Versionen.
2. Composer bringt die Erweiterungen passend zur neuen composer.json auf den neuesten Stand: Neue Erweiterungen werden geklont, vorhandene Klone wechseln auf ihre neuen Release-Tags.

Beide Schritte lassen sich auf der Kommandozeile (Weg A) oder in der Administration (Weg B) ausführen. Diese Seite beschreibt beide Wege nebeneinander mit denselben sieben Schritten, sagt, was jeder kann und was nicht, und wie Sie sie kombinieren.

Kommandozeile oder Administration? #

Kurz gesagt: Weg A kann alles. Weg B deckt ein Routine-Update einer Site ab, die einem Branch folgt (main oder Ihrem eigenen Branch, in den Sie Releases mergen), ohne eine Shell zu öffnen; ein Release-Tag, ein Merge-Konflikt und der Neustart von Velocity brauchen aber weiterhin die Kommandozeile.

Wählen Sie, wie eng Sie folgen #

Release-Tags liegen auf der Historie von main. Sie können also mit Releases beginnen und später zu main wechseln, oder umgekehrt, sobald das nächste Release aufgeholt hat.

Die sieben Schritte #

Weg A: die Kommandozeile #

Führen Sie jeden Befehl im Wurzelverzeichnis der Installation aus, als der Benutzer, dem die Dateien gehören (nicht als root: Als root verlangen die Skripte in bin/php/ die Option --allow-root-user). Die Bilder zeigen die echte Ausgabe der Befehle in einer Testinstallation: ein Kernel-Klon auf dem Branch my-site, erstellt aus dem Release v6.0.13, jede Erweiterung ein Git-Klon, aktualisiert auf main. Die Aufnahmen entstanden als root und zeigen deshalb --allow-root-user; die zweizeilige Warnung, die root von jedem Skript bekommt, ist weggelassen.

A1. Sichern und das Wartungsfenster beginnen #

Sichern Sie die Datenbank (mit dem Dump-Werkzeug Ihrer Datenbank) und das Verzeichnis. Nehmen Sie dann die öffentliche Site offline:

php bin/php/maintenance.php on --message="Updating, back at 06:00" --until=1h
php bin/php/maintenance.php status

maintenance.php ist Teil von 6.0.15 (main); bei einem älteren Release überspringen Sie diesen Schritt oder schalten die Wartung in der Administration ein (B1), was funktioniert, sobald der neue Code installiert ist.

A2. Sehen, was ansteht #

git status --short --untracked-files=no
git fetch origin --tags
git log --oneline HEAD..origin/main | head -5
git log --oneline HEAD..origin/main | wc -l
git tag -l 'v6.*' --sort=version:refname | tail -3

git status darf nichts ausgeben: Änderungen, die Sie nicht committet haben, können den Merge verhindern. HEAD..origin/main listet auf, was die Entwicklungslinie bringen würde; für ein Release leistet HEAD..v6.0.14 dasselbe. Sortieren Sie Tags immer nach Version (nach Namen kommt v6.0.10 vor v6.0.8). composer outdated 'se7enxweb/*' nennt die Erweiterungen, für die es ein neueres Release gibt.

A3. Den Kernel mit Git aktualisieren #

Wenn Sie der Entwicklungslinie folgen:

git merge --no-edit origin/main

Wenn Sie nur Releases folgen, der neueste Release-Tag:

git merge --no-edit "$(git tag -l 'v6.*' --sort=version:refname | tail -1)"

git merge behält Ihre eigenen Commits auf my-site und fügt die neuen hinzu. Wenn einer Ihrer Commits und das Update dieselben Zeilen ändern, hält Git mit CONFLICT an; git merge --abort stellt alles wieder her.

Auf einem Klon ohne eigenen Branch (HEAD detached at v6.0.14) wechseln Sie stattdessen auf das neue Release: git switch --detach "$(git tag -l 'v6.*' --sort=version:refname | tail -1)".

A4. Die Erweiterungen mit Composer aktualisieren #

composer update
composer status -v

composer update, nicht composer install: Die composer.json des Kernels hat sich geändert, und Ihre Lock-Datei (sie gehört nicht zum Repository des Kernels) muss ihr folgen. Von v6.0.13 nach main kamen dabei 39 Pakete hinzu und 11 wurden aktualisiert, jedes neue se7enxweb/*-Paket als Git-Klon dank der Einstellung preferred-install aus Mit Git entwickeln. Am Ende werden die Klassen-Maps neu erzeugt.

Was Composer mit Klonen macht:

• Ein Update behält die Art bei, wie ein Paket zuerst installiert wurde: Ein Klon bleibt ein Klon, ein Archiv bleibt ein Archiv, auch mit --prefer-source. composer reinstall <package> macht aus einem Archiv einen Klon (Mit Git entwickeln).
• Es überschreibt nie Ihre Arbeit: Ein Klon mit nicht committeten Änderungen oder mit Commits auf einem Branch, den es nur auf Ihrem Rechner gibt, hält es mit einer Meldung an (Wenn Composer sich weigert). Beheben Sie die Ursache und führen Sie composer update erneut aus, um abzuschließen.

A5. Die Datenbank prüfen und aktualisieren #

php bin/php/checkmanifest.php --all
ls update/database/mysql/6.0/

checkmanifest.php --all vergleicht jede Datei mit den Prüfsummen des Release; nach einem sauberen Git-Update meldet es, dass sie übereinstimmen. Ein Release kann ein Datenbank-Update brauchen: Upgrade nennt die Datei für jedes Release und jede Datenbank-Engine (update/database/<engine>/6.0/...). Spielen Sie sie einmal ein, vollständig und in der richtigen Reihenfolge, mit dem Client Ihrer Datenbank, zum Beispiel:

mysql -u USER -p DATABASE < update/database/mysql/6.0/dbupdate-6.0.0-6.0.15.sql

(Die Testinstallation hat keine Datenbank, daher gibt es von diesem Schritt kein Bild.)

A6. Die Caches leeren und den Code neu laden #

php bin/php/ezcache.php --clear-all

Auf einer Site, die von Exponential Velocity ausgeliefert wird, führen Sie stattdessen php bin/php/console exp:velocity deploy aus: Es erzeugt die Klassen-Maps neu, leert die Caches, macht PHP-FPM den neuen Code bekannt und startet Velocity neu, in der richtigen Reihenfolge (Velocity-Engines).

A7. Die Site prüfen und das Wartungsfenster beenden #

git log --oneline ORIG_HEAD..HEAD | wc -l
php bin/php/console --version
php bin/php/maintenance.php off

Nach einem Merge zeigt ORIG_HEAD auf den Stand davor: git log --oneline ORIG_HEAD..HEAD listet auf, was das Update gebracht hat. Öffnen Sie die Titelseite und die Administration und lesen Sie die Logs (var/log/error.log oder Setup > Logdateien > Fehlerübersicht in der Administration), bevor Sie die Wartung ausschalten. Um stattdessen zurückzugehen: git reset --hard ORIG_HEAD, dann composer update (von main zurück auf v6.0.13 entfernt das die 39 hinzugekommenen Pakete und setzt 11 zurück), und stellen Sie die Datenbank aus der Sicherung wieder her, falls ein Datenbank-Update gelaufen ist.

Weg B: die Administration #

Dieselben sieben Schritte auf den Seiten der Administration. Die Screenshots zeigen das Design Admin 4 mit einem Test-Administrator; Hostnamen, Serverpfade und Adressen sind durch Beispiele ersetzt. Jede Seite braucht eine Richtlinie (module/function); die Rolle Administrator hat sie alle.

Die Git-Verwaltung, „Aktualisierungen und Pakete“ und der DS-Editor sind Erweiterungen (git_manager, ezupdate, sevenx_dse); sie erscheinen im Menü, wenn sie aktiv sind.

B1. Sichern und das Wartungsfenster beginnen #

Legen Sie eine Sicherung an: Setup > Sicherung, Typ Sicherung von Datenbank und Dateien. Öffnen Sie dann Setup > Wartung. Solange die Site online ist, zeigt die Seite ein grünes Banner Die Website ist online und einen Plan in drei Schritten:

1. Nachricht für Besucher (optional; bleibt das Feld leer, zeigt die Seite „We are working on the site and will be back shortly.“).
2. Voraussichtliche Dauer: Geben Sie die Minuten ein oder wählen Sie 15 min, 30 min, 1 h, 2 h oder 4 h. Die Wartung endet nicht von selbst.
3. Wer weiterhin Zugang hat: die Administration unter /admin immer; kreuzen Sie Meine eigene Adresse sieht die Website weiterhin an, um Ihre Arbeit zu prüfen, während alle anderen die Wartungsseite erhalten.

Kreuzen Sie Mir ist bewusst, dass die öffentliche Website für jeden oben nicht aufgeführten Besucher offline geht, bis ich den Wartungsmodus wieder ausschalte. an und klicken Sie auf Website offline nehmen. Die Vorschau zeigt die Seite, die Besucher erhalten.

B2. Sehen, was ansteht #

Öffnen Sie Setup > Git-Verwaltung und klicken Sie in der Karte Upstream (origin) auf Jetzt holen. Das führt git fetch --prune aus und sonst nichts. Die Karte zeigt dann das Remote, den Branch, mit dem verglichen wird, Voraus / zurück (lokale Commits / zu holende Commits), die Dateien unter Nicht committet und Fehlt in dieser Installation: die Commits, die das Update bringt, jeweils mit Autor und Link. Dateien, die Sie geändert und nicht committet haben, können den nächsten Schritt scheitern lassen; committen Sie sie vorher in einer Shell.

Aktualisierungen und Pakete > Übersicht > Nach Aktualisierungen suchen zeigt, welche Erweiterungen ein neueres Release haben; es ändert nichts.

B3. Den Kernel mit der Git-Verwaltung aktualisieren #

Wählen Sie unter Lokaler Branch den Branch, auf dem die Site läuft (den hinter HEAD angezeigten, zum Beispiel main oder my-site), kreuzen Sie Autoloads neu erzeugen an und klicken Sie auf Auschecken. Die Git-Verwaltung checkt diesen Branch aus und führt git pull origin <branch> aus: Sie holt den gleichnamigen Branch von GitHub, mergt ihn und erzeugt die Klassen-Maps neu. Die Ausgabe von Git wird auf der Seite angezeigt; das Badge zeigt danach Aktuell, und Voraus / zurück zeigt 0 / 0.

Die Git-Verwaltung folgt Branches. Einen Release-Tag kann sie nicht in Ihren Branch mergen; für Updates nur auf Releases verwenden Sie A3. Der Commit-Verlauf weiter unten listet die Historie auf, 50 Commits pro Seite, mit einem Filter nach Autor und Datum; ein Commit lässt sich über seinen Hash auschecken (um zurückzugehen).

B4. Die Erweiterungen mit „Aktualisierungen und Pakete“ aktualisieren #

Die Seite Aktualisierungen und Pakete führt Composer für Sie aus: im Verzeichnis der Installation, im Hintergrund, als der Benutzer, unter dem das PHP des Webservers läuft, mit einem Zeitlimit. Sie tut, was composer update in A4 tut. Das Aktualisieren steht auf Ausgeschaltet, bis Sie etwas anderes wählen ([UpdateSettings] AllowUpdate), weil Composer vendor/ und die Dateien jedes Pakets, das es aktualisiert, neu schreibt.

1. Holen als: auto, dist (archives) oder source (git, with history). Wählen Sie source, damit neue Erweiterungen als Git-Klone ankommen; bereits installierte Pakete behalten die Art, wie sie installiert wurden.
2. Vorschau (Probelauf) führt composer update --dry-run aus und zeigt, was sich ändern würde. Sie öffnet die Seite des Laufs.
3. Um etwas zu ändern, muss das Aktualisieren eingeschaltet sein: Updates einschalten (schreibt AllowUpdate=enabled in settings/override/ezupdate.ini.append.php).
4. Ein vollständiges Update, das der neuen composer.json des Kernels folgt: Kreuzen Sie auf der Seite des Probelaufs (bei eingeschaltetem Aktualisieren bietet sie neben Erneut ausführen auch Wirklich ausführen an) Eine Sicherung von Dateien und Datenbank ist vorhanden an und klicken Sie auf Wirklich ausführen. Updates installieren in der Übersicht aktualisiert dagegen nur die Pakete, die Sie nach Nach Aktualisierungen suchen angekreuzt haben.
5. Die Seite verfolgt die Ausgabe von Composer während des Laufs. Danach werden die Klassen-Maps neu erzeugt und die INI-, Template- und Inhalts-Caches geleert. Ein Hinweis meldet The installation is up to date! oder was sich geändert hat. Schalten Sie das Aktualisieren wieder aus.

Die anderen Reiter helfen Ihnen beim Prüfen vorher und nachher:

• Installierte Pakete stellt nebeneinander, was composer.json verlangt, was composer.lock aufgelöst hat, was auf der Festplatte liegt und welche Erweiterungen eingeschaltet sind; Braucht Aufmerksamkeit zeigt, was nicht übereinstimmt, Git-Klone, welche Pakete Klone sind.
• Pakete finden durchsucht packagist.org und markiert, was installiert ist.
• Paketserver listet die Composer-Server (packagist.org lässt sich ausschalten) und die .ezpkg-Paketserver auf.
• Förderung zeigt, wer hinter den installierten Paketen steht und wie Sie sie unterstützen können.

B5. Die Datenbank prüfen und aktualisieren #

Setup > Upgrade-Prüfung hat zwei Prüfungen; beide lesen nur. Überprüfe Dateikonsistenz vergleicht jede Datei mit den Prüfsummen des Release (nach einem sauberen Git-Update stimmt jede Datei überein). Überprüfe Datenbankkonsistenz vergleicht die Tabellen mit dem Schema des neuen Codes und zeigt das SQL, das die Datenbank angleichen würde; SQL herunterladen speichert es.

Ein Release kann ein Datenbank-Update brauchen: Upgrade nennt die Datei. Ohne Shell öffnet Setup > DS-Editor die Datenbank der Site in AdminNeo, nachdem Sie eine Warnseite bestätigt haben (Ich habe eine vollständige Sicherung erstellt und übernehme die volle Verantwortung., Weiter zur Datenbank); dort können Sie SQL ausführen oder die Datei des Release importieren. Das wirkt auf die Live-Daten, an allen Prüfungen der Administration vorbei. Führen Sie danach Überprüfe Datenbankkonsistenz erneut aus.

B6. Die Caches leeren #

Setup > Cache-Verwaltung: Alle Caches leeren … und bestätigen. Auf einer Site, die von Exponential Velocity ausgeliefert wird, außerdem Antwort-Cache von Velocity leeren (Gruppe Seiten, Abfragen und der Server). Die Administration kann Velocity nicht neu starten: Nach einem Update, das PHP-Code ändert, behalten die Worker von Velocity die alten Klassen, bis php bin/php/console exp:velocity restart (oder exp:velocity deploy) auf der Kommandozeile läuft; die Seite weist an den entscheidenden Stellen darauf hin. Eine Site, die von Apache oder nginx mit PHP-FPM ausgeliefert wird, übernimmt den neuen Code normalerweise von selbst (OPcache prüft die Dateien erneut).

B7. Die Site prüfen und das Wartungsfenster beenden #

Öffnen Sie die Titelseite und einige typische Seiten (mit angekreuztem Meine eigene Adresse sieht die Website weiterhin sehen Sie die Site, alle anderen die Wartungsseite) sowie ein Objekt in der Administration. Dann Setup > Logdateien: Fehlerübersicht listet die verschiedenen Fehler und Warnungen der letzten 24 Stunden auf, die häufigsten zuerst; Zustand der Logs zeigt die am schnellsten wachsenden Logs und die Dateien, die der Webserver nicht schreiben kann. Entscheidend sind die Fehler, die seit dem Update neu sind.

Erst wenn alles in Ordnung ist: Setup > Wartung > Website wieder online bringen. Wenn etwas nicht in Ordnung ist, gehen Sie zuerst zurück: Checken Sie in der Git-Verwaltung im Commit-Verlauf den Commit aus, auf dem die Site vorher lief, führen Sie das vollständige Update in „Aktualisierungen und Pakete“ erneut aus und stellen Sie die Datenbank aus der Sicherung wieder her, falls ein Datenbank-Update gelaufen ist.

Checkliste

• To do: Sicherung angelegt (Setup > Sicherung)
• To do: Wartung eingeschaltet (Setup > Wartung > Website offline nehmen)
• To do: Kernel aktualisiert (Git-Verwaltung: Jetzt holen, Auschecken des Branches der Site mit Autoloads neu erzeugen; Badge Aktuell)
• To do: Erweiterungen aktualisiert (Aktualisierungen und Pakete: Vorschau (Probelauf), Wirklich ausführen; Aktualisieren wieder ausgeschaltet)
• To do: Upgrade-Prüfung: Dateien und Datenbank konsistent; das Datenbank-Update des Release eingespielt
• To do: Caches geleert (Cache-Verwaltung > Alle Caches leeren …; Antwort-Cache von Velocity und ein Neustart von Velocity aus einer Shell)
• To do: Titelseite, einige Seiten und die Administration funktionieren
• To do: Logdateien > Fehlerübersicht: keine neuen Fehler
• To do: Wartung ausgeschaltet (Website wieder online bringen)

Die beiden Wege kombinieren #

Beide Wege arbeiten auf denselben Dateien und lassen sich daher kombinieren, zum Beispiel die Git-Verwaltung für den Kernel und Composer auf der Kommandozeile für die Erweiterungen. Die Regeln:

1. Immer in der Reihenfolge der Schritte: zuerst Git, dann Composer, dann die Datenbank, dann die Caches. Composer liest die composer.json, die der Kernel gerade hat; läuft es, bevor der Kernel aktualisiert wurde, aktualisiert es auf die alte Liste.
2. Immer nur ein Composer zur Zeit. Starten Sie composer update nicht auf der Kommandozeile, während ein Lauf von „Aktualisierungen und Pakete“ noch läuft (die Übersicht zeigt ihn unter Letzte Läufe), und umgekehrt.
3. Derselbe Benutzer. „Aktualisierungen und Pakete“ führt Composer als Benutzer des Webservers aus; führen Sie Git und Composer auf der Kommandozeile als derselbe Benutzer aus (sudo -u www-data composer update, mit dem Benutzer Ihres Webservers), damit die Dateien nicht am Ende zwei verschiedenen Benutzern gehören, sodass der Webserver sie nicht mehr überschreiben kann.
4. Starten Sie Velocity auf der Kommandozeile neu, nachdem einer der beiden Wege PHP-Code auf einer Velocity-Site geändert hat.

Sichere Kombinationen:

Automatisch aktualisieren lassen #

Wenn Sie das Update einige Male von Hand ausgeführt haben und ihm vertrauen, kann ein kleines Skript es nach Ihrem Zeitplan erledigen. Testen Sie es zuerst von Hand auf einer Staging-Kopie und lassen Sie die Live-Site auf Releases. Ein automatisches Update führt nie Datenbank-Updates aus, und es hält an, statt zu raten, wenn etwas einen Menschen braucht.

Speichern Sie Folgendes als /usr/local/bin/exp-update und machen Sie es ausführbar (chmod +x /usr/local/bin/exp-update):

#!/bin/sh
# exp-update: bring an Exponential installation made of Git clones up to date.
#   exp-update release   the newest release tag of the 6.x line (v6.*)
#   exp-update main      the development line, origin/main
# Stops without changing anything when the kernel has uncommitted changes or the merge needs a hand.
set -eu
SITE=${EXP_SITE:-/var/www/exponential}
MODE=${1:-release}
cd "$SITE"
if [ -n "$(git status --porcelain --untracked-files=no)" ]; then
    echo "exp-update: the kernel has uncommitted changes; commit or stash them first" >&2
    exit 1
fi
git fetch --quiet origin --tags
if [ "$MODE" = main ]; then
    TARGET=origin/main
else
    TARGET=$(git tag -l 'v6.*' --sort=version:refname | tail -1)
fi
if git merge-base --is-ancestor "$TARGET" HEAD; then
    echo "exp-update: already up to date with $TARGET"
    exit 0
fi
if ! git merge --no-edit "$TARGET"; then
    git merge --abort
    echo "exp-update: merging $TARGET needs a hand; nothing was changed" >&2
    exit 1
fi
composer update --no-interaction --no-progress
php bin/php/ezcache.php --clear-all
echo "exp-update: now at $(git describe --tags --always)"

Setzen Sie EXP_SITE auf das Verzeichnis Ihrer Installation. Was es tut, wie getestet:

Auf einer Site, die von Velocity ausgeliefert wird, ersetzen Sie die Zeile mit ezcache.php durch php bin/php/console exp:velocity deploy.

Mit cron #

Bearbeiten Sie die Crontab des Benutzers, dem die Dateien gehören (crontab -e), und fügen Sie eine dieser Zeilen hinzu:

# every hour, the development line
5 * * * *   EXP_SITE=/var/www/exponential /usr/local/bin/exp-update main >> $HOME/exp-update.log 2>&1
# every day at 04:15, the development line
15 4 * * *  EXP_SITE=/var/www/exponential /usr/local/bin/exp-update main >> $HOME/exp-update.log 2>&1
# every Monday at 04:15, the development line
15 4 * * 1  EXP_SITE=/var/www/exponential /usr/local/bin/exp-update main >> $HOME/exp-update.log 2>&1
# on the first of every month at 04:15, the development line
15 4 1 * *  EXP_SITE=/var/www/exponential /usr/local/bin/exp-update main >> $HOME/exp-update.log 2>&1
# every day at 04:15, but only when a new release has been published
15 4 * * *  EXP_SITE=/var/www/exponential /usr/local/bin/exp-update release >> $HOME/exp-update.log 2>&1

Eine tägliche Prüfung im Modus release aktualisiert nur an dem Tag, an dem ein neues Release erscheint; an allen anderen Tagen gibt sie already up to date aus.

Mit einem systemd-Timer #

Zwei Dateien in /etc/systemd/system/. exp-update.service:

[Unit]
Description=Update the Exponential installation from GitHub
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=www-data
Environment=EXP_SITE=/var/www/exponential
ExecStart=/usr/local/bin/exp-update release

und exp-update.timer:

[Unit]
Description=Update the Exponential installation from GitHub, daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

Tragen Sie bei User= den Benutzer ein, dem Ihre Dateien gehören, und bei ExecStart= main, um der Entwicklungslinie zu folgen. OnCalendar= akzeptiert hourly, daily, weekly (montags), monthly (am Ersten des Monats) oder eine Zeitangabe wie *-*-* 04:15:00; systemd-analyze calendar weekly zeigt, wann er laufen würde. Dann:

systemctl daemon-reload
systemctl enable --now exp-update.timer
systemctl list-timers exp-update.timer
journalctl -u exp-update.service

Die letzten beiden Befehle zeigen, wann er das nächste Mal läuft und was er beim letzten Mal gemeldet hat.

Wie es weitergeht #

• Mit Git entwickeln: als Klone installieren, auf einem Branch arbeiten, Korrekturen zurückschicken.
• Erweiterungen zurückgeben: Ihre eigenen Erweiterungen veröffentlichen, damit alle sie nutzen können, und was die GPL verlangt, wenn Sie eine weitergeben.
• Upgrade: die Schritte für Datenbank und Einstellungen bei jedem Release.
• Die Upgrade-Prüfung und git_manager.
• Das Projekt auf GitHub: se7enxweb/exponential und seine Releases.