Skip to content

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:

  1. #!/bin/bash
  2. cd /var/www</p>
  3.  
  4. <p>echo &#8220;&#8212;&#8212;> Save config, plugins, themes and uploads &#8230;&#8221;
  5. 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>
  6.  
  7. <p>echo &#8220;&#8212;&#8212;> Downloading &#8230;&#8221;
  8. wget https://github.com/s9y/Serendipity/archive/master.zip</p>
  9.  
  10. <p>echo &#8220;&#8212;&#8212;> Unzipping &#8230; (to Serendipity-master/)&#8221;
  11. unzip master.zip</p>
  12.  
  13. <p>echo &#8220;&#8212;&#8212;> Deleting current installation &#8230;&#8221;
  14. rm -r s9y-testblog
  15. echo &#8220;&#8212;&#8212;> Restore config, plugins, themes and uploads &#8230;&#8221;
  16. tar -xzf s9y-testblog-backup.tgz
  17. echo &#8220;&#8212;&#8212;> Install new files &#8230;&#8221;
  18. cp -ar Serendipity-master/* s9y-testblog/
  19. echo &#8220;&#8212;&#8212;> Cleanup &#8230;&#8221;
  20. rm master.zip
  21. rm s9y-testblog-backup.tgz
  22. rm -r Serendipity-master/</p>
  23.  
  24. <p>echo &#8220;&#8212;&#8212;> Log last commit&#8221;
  25. curl https://api.github.com/repos/s9y/Serendipity/commits/master -H &#8220;Accept: application/vnd.github.v3.sha&#8221; > 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:

  1. #!/bin/bash
  2. cd /var/www</p>
  3.  
  4. <h1 id="log-last-commit">Log last commit</h1>
  5.  
  6. <p>curl https://api.github.com/repos/s9y/Serendipity/commits/master -H &#8220;Accept: application/vnd.github.v3.sha&#8221; > s9y-testblog/COMMIT-ID</p>
  7.  
  8. <h1 id="update">Update</h1>
  9.  
  10. <p>wget https://github.com/s9y/Serendipity/archive/master.zip
  11. unzip master.zip
  12. cp -ar Serendipity-master/* s9y-testblog/
  13. rm master.zip
  14. rm -r Serendipity-master/

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

mitch am :

mitch

Ich muss jetzt einfach meinen Senf dazugeben, obwohl ich gar kein s9y-Testblog habe :-) Folgende Idee:

  • Runterladen und Testblog versorgen trennen (nur noch letzteres im Skript behalten)
  • nicht mehr das master.zip jedes Mal komplett runterladen, sondern lokal den ganzen git-tree von s9y vorhalten (einfach ein git clone irgendwohin)
  • das Testblog statt aus dem entzippten master.zip aus dem git-tree befüllen
    • cp -ar würde auch das .git-Unterverzeichnis mitkopieren – das stört nicht, frisst aber Platz. Tricksen könntest Du mit zweimal tar statt cp: (cd /quelle; tar -c --exclude-vcs) | ( cd /ziel; tar -xv)
  • die aktuelle ausgecheckte Version kriegst Du über git describe aus dem git-tree

Das hätte folgende Vorteile:

  • Du kannst mit git pullim git-tree wie bisher zur neuesten Version springen
  • Du kannst aber auch mit git checkout zu einem beliebigen alten Stand springen oder auf irgendeinen Branch wechseln
  • Und Du kannst Dich mit git bisect auf die Jagd nach Bugs machen
  • keine Race-Condition bei der Commit-ID mehr ;-)

Meinjanur O:-)

Thomas Hochstein am :

Thomas Hochstein

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.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen