Bau der MueSLi-Homepage mit Git/Gitolite/lektor und ein paar Skripten

von Frank Rocholl am Montag, 23. April 2018

Nachdem die MueSLi-Homepage schon etwas in die Jahre gekommen ist haben wir auf unseren Stammtisch den Entschluß gefasst eine neues Webteam zu bilden und die Homepage mit einfachen Mitteln in das neue Jahrtausend zu führen.

Anforderungen

Implementierung

Die Verwaltung der Homepage erfolgt gleichberechtig von allen Mitgliedern des Webteams. Jeder pflegt Webseiten auf seinem lokalen PC und checkt diese dann in ein zentrales Git-Repository ein.

MuesLi-Branching-Modell

Daneben kann es Interims-Branches geben (wie z.B. lektor_vorschlag). Die kann man später wieder löschen.

Rechteverwaltung mit Gitolite

Im Gitolite kann man mit wenigen Zeilen das Rechtekonzept umsetzen. Hier Auszüge aus der gitolite.conf

repo www.mueslihq.de
    RW+     = webteam-member1@mueslihq.de webteam-member2@mueslihq.de webteam-member3@mueslihq.de
    RW master = webteam-member1@mueslihq.de webteam-member2@mueslihq.de webteam-member3@mueslihq.de
    R       = auschecker@mueslihq.de

Praxisbeispiel: Erstellung einer neuen Webseite

Will man die MueSLi-Webseite editieren, so ist diese zuerst aus der Versionsverwaltung auszuchecken:

git clone git@git.hottemax.org:www.mueslihq.de

Will man eine tolle Änderung, so erstellt man sich zuerst einen eigenen Branch auf Basis des master-Branches:

git checkout -b tolle-aenderung 

Hier kann man nach Belieben editieren. Änderungen sind mit git commit -a zu committen.

Ist die Modifikation abgeschlossen, so ist der neuen Zweig in den master-Branch zu mergen:

git checkout master
git merge tolle-aenderung

Will man die Änderungen auf dem Entwicklungsserver dev.mueslihq.de checken, so ist der Branch in den dev-Branch zu überführen und auf den Server zu pushen.

git checkout dev
git merge master
git push origin dev

Analog ist mit dem qual-Branch zu verfahren. Das Ergebnis kann man sich anschauen unter qual.mueslihq.de.

git checkout qual
git merge master
git push origin qual

Wenn dann alles OK ist, kann man die MuesLi-Homepage https://mueslihq.de erzeugen mittels:

git checkout prod
git merge master
git push origin prod

Es ist nicht notwendig den gesamten Lebenszyklus eines Dokumementes zu durchschreiten. Man kann natürlich dirket den master-Branch mit dem prod-Branch mergen, wenn keine weitere Person sich die Änderungen angucken muß.

Im master-Branch sind ja alle Änderungen festgeschrieben und man kann immer wieder zurück wenn es den andern Mitgliedern des MueSLi-Webteams nicht gefällt.

Anpassungen für Lektor im Betriebssystem

Betreibt man Lektor auf seiner Workstation im server-Modus (lektor server), so kann es in seltenen Fällen Probleme mit der Höhe des "inotify watch limit"s geben. Der Standardwert von 8192 ist manchmal zu klein (cat /proc/sys/fs/inotify/max_user_watches).

Man kann diesen Wert jedoch einfach erhöhen:

sysctl fs.inotify.max_user_watches=524288
sysctl -p

Weitere Details dazu gibt es hier.

Skripte auf dem Server

Nach der Generierung der statischen Seiten werden noch dynamische Inhalte, wie Anzahl der MueSLis-Mitglieder, hinzu gerendert. Der funktionale User muesli-macher lässt um 00:00h das Skript muesli-daily.sh laufen. Dieses

Alle Änderungen werden automatisiert in den Lektor Dateien gemacht und dann ins Git in den master und prod branch eingecheckt. Der Automat rendert daraus wieder statische HTML-Dateien. So stellt man sicher, dass jede Änderung revisionssicher ist.

Auf dem Git-Server läuft ein Hook, der bei einem push mittels lektor build $DOCUMENT_ROOT die Webseiten rendert und diese dann auf den eigentlichen Web-Server kopiert.