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.
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.
master-Branch: In diesem sollten alle Daten gemerged werden, die Bestand haben sollen. Man kann keine Versionen aus diesem Branch löschen sondern nur Neue erzeugen. Ein Rebase ist nicht erlaubt.
dev-Branch: (wird ausgecheckt unter dev.mueslihq.de): Dieser Branch steht für die (Web)-Entwickler zur Verfügung. Will man als (Web)-Entwickler mit den Anderen Dinge diskutieren kann man sagen: "Schau Dir mal die DEV" an. Per Definition kann der Branch auch mal kaputt sein.
qual-Branch: (wird ausgecheckt unter qual.mueslihq.de): Hier kann man anderen (Nicht Entwicklern) sagen: "Schau Dir mal die Inhalte an. Ist das OK so?"
prod-Branch: (wird ausgecheckt unter https://mueslihq.de). Das ist unsere Live Homepage.
archive-Branch: Die Branch beinhaltet nicht mehr gültige, oder noch nicht noch nicht veröffentlichungswürdige Dokumente. Dieser Branch kann nicht zurückgespult werden und dient als Archiv.
Daneben kann es Interims-Branches geben (wie z.B. lektor_vorschlag). Die kann man später wieder löschen.
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
RW archive = webteam-member1@mueslihq.de webteam-member2@mueslihq.de webteam-member3@mueslihq.de
R = auschecker@mueslihq.de
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 Dokumentes zu durchschreiten. Man kann natürlich direkt 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.
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.
In das Deployment sind 2 Server involviert:
php_value engine off).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:01h 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 synchronisiert.