Ein Serendipity-Testblog auf dem aktuellen Stand halten
Wenn man das Weblog-System Serendipity nicht nur nutzt, sondern auch testen möchte, empfiehlt es sich, neben dem “echten” eigenen Blog (der Live-Instanz) auch ein Testblog zu betreiben. Dort kann man dann jeweils den neuesten Code aus git auschecken und testen.
Um sicherzugehen, dass es sich auch wirklich um einen frischen Checkout handelt und nicht noch irgendwelche Dateien aus früheren Versionen “herumliegen”, lösche ich gerne die bisherige Installation und setze sie frisch auf. Dabei sollen aber die Datenbanken sowie vorhandene Plugins und Themes und Medien erhalten bleiben.
Für diesen Zweck verwende ich ein passendes Shellscript:
- #!/bin/bash
- cd /var/www</p>
- <p>echo “——> Save config, plugins, themes and uploads …”
- tar -czf s9y-testblog-backup.tgz s9y-testblog/serendipity_config_local.inc.php s9y-testblog/.htaccess s9y-testblog/plugins/* s9y-testblog/templates/* s9y-testblog/uploads/*</p>
- <p>echo “——> Downloading …”
- wget https://github.com/s9y/Serendipity/archive/master.zip</p>
- <p>echo “——> Unzipping … (to Serendipity-master/)”
- unzip master.zip</p>
- <p>echo “——> Deleting current installation …”
- rm -r s9y-testblog
- echo “——> Restore config, plugins, themes and uploads …”
- tar -xzf s9y-testblog-backup.tgz
- echo “——> Install new files …”
- cp -ar Serendipity-master/* s9y-testblog/
- echo “——> Cleanup …”
- rm master.zip
- rm s9y-testblog-backup.tgz
- rm -r Serendipity-master/</p>
- <p>echo “——> Log last commit”
- curl https://api.github.com/repos/s9y/Serendipity/commits/master -H “Accept: application/vnd.github.v3.sha” > s9y-testblog/COMMIT-ID
Das Script setzt voraus, dass das Testblog in /var/www/s9y-testblog
installiert wurde; Pfade müssen ansonsten angepasst werden. Es sichert die lokale Konfiguration (einschließlich einer bestehenden .htaccess
-Datei) sowie die Verzeichnisse für Plugins, Themes und die Mediendaten, bevor es die Dateien aus dem aktuellen Master-Branch lädt; die ZIP-Datei wird dann nach Serendipity-master
entpackt. Danach wird das alte Testblog-Verzeichnis gelöscht; dann werden die gesicherten Dateien einkopiert und schließlich der Inhalt des Master-Branches überkopiert. Diese Reihenfolge ist wichtig, damit nicht eventuelle Updates von Plugins oder Templates, die mit dem Serendipity-Kern verteilt werden, durch das eingespielte Backup überschrieben werden. Am Schluss werden temporäre Dateien gelöscht und die Commit-ID des aktuellen HEAD
des Master-Branches in einer Datei COMMIT-ID
gespeichert. (Klar, da gibt es eine Race-Condition, weil möglicherweise jemand zwischen dem Laden der Daten und der Speicherung der Commit-ID neue Commits gepushed haben kann - für meine Zwecke reicht das aber.)
Alternativ kann man sich natürlich das Löschen und Neuaufsetzen sparen und einfach nur die neuen Dateien überkopieren; so lässt sich auch der Upgrade-Pfad testen. Das ginge dann vereinfacht so:
- #!/bin/bash
- cd /var/www</p>
- <h1 id="log-last-commit">Log last commit</h1>
- <p>curl https://api.github.com/repos/s9y/Serendipity/commits/master -H “Accept: application/vnd.github.v3.sha” > s9y-testblog/COMMIT-ID</p>
- <h1 id="update">Update</h1>
- <p>wget https://github.com/s9y/Serendipity/archive/master.zip
- unzip master.zip
- cp -ar Serendipity-master/* s9y-testblog/
- rm master.zip
- rm -r Serendipity-master/
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
mitch am :
Ich muss jetzt einfach meinen Senf dazugeben, obwohl ich gar kein s9y-Testblog habe Folgende Idee:
master.zip
jedes Mal komplett runterladen, sondern lokal den ganzen git-tree von s9y vorhalten (einfach eingit clone
irgendwohin)master.zip
aus dem git-tree befüllencp -ar
würde auch das.git
-Unterverzeichnis mitkopieren – das stört nicht, frisst aber Platz. Tricksen könntest Du mit zweimaltar
stattcp
:(cd /quelle; tar -c --exclude-vcs) | ( cd /ziel; tar -xv)
git describe
aus dem git-treeDas hätte folgende Vorteile:
git pull
im git-tree wie bisher zur neuesten Version springengit checkout
zu einem beliebigen alten Stand springen oder auf irgendeinen Branch wechselngit bisect
auf die Jagd nach Bugs machenMeinjanur O:-)
Thomas Hochstein am :
Das hat natürlich einiges für sich.
Ich arbeite selbstverständlich auch mit dem Git-Repository, aber auf meinem Desktoprechner bzw. dem Laptop (und unter Windows). Das Testblog möchte ich im Netz erreichbar haben. Insoweit sind die Vorteile vergleichbar relativ - einen bestimmten Stand brauche ich in der Regel nicht, und mit git bisect arbeite ich lieber lokal als irgendwo auf einer Maschine im Netz per SSH.
Mein ursprüngliches Motiv für den Download des ZIPs war einerseits, dass ich dann kein (ansonsten überflüssiges) Git-Repository brauche - gut, Speicherplatz spielt nicht wirklich eine Rolle -, und andererseits, dass sich der Download eines ZIPs scripten lässt, ein
git pull
aber durchaus auch einmal fehlschlagen kann, wenn sich im Repository Schweinereien (bspw. ein Rebase) ereignet haben.