WordPress Git-Unterstützung mit Revisr

Revisr ist ein Word­Press-Plugin, mit dem man sei­ne Blog-Kon­fi­gu­ra­ti­on über Git ver­wal­ten kann. Ist es auch für mei­ne Ent­wick­lungs­um­ge­bung geeig­net?

Entwicklungsaktivität bei Revisr

Die letz­te Major Release von Revisr (2.0.2) ist bereits vom Dezem­ber 2015. Das bedeu­tet nor­ma­ler­wei­se nichts gutes, denn drei Jah­re sind unter IT-Bedin­gun­gen eine Ewig­keit. Auch im Sup­port-Forum fin­det man nur weni­ge neue Anfra­gen, und die letz­te Ant­wort des Plugin-Autors ist über zwei Jah­re alt.

Aller­dings ist das Plug­in­laut Word­Press-Repo­sito­ry das letz­te mal vor 2 Mona­ten upge­da­ted wor­den und mit der aktu­el­len Word­Press-Ver­si­on (5.0.3) getes­tet.

Mög­li­cher­wei­se bestand die­ses Update aber nur aus genau die­ser Ver­si­ons­in­for­ma­ti­on? Die­ser Ver­dacht bestä­tigt sich beim Blick in den Deve­lop­ment Log:

In den letz­ten 3 Jah­ren ist also nicht sub­stan­zi­el­les an dem Pro­jekt gesche­hen. Das muss nicht schlech­tes bedeu­ten, denn fie Funk­tio­na­li­tät von Git hat sich in die­ser Zeit ja auch nicht revo­lu­tio­när ver­än­dert. Es lässt aber nicht gutes für die Zukunft ahnen, wenn sich even­tu­ell auf Word­Press-Sei­te Ände­run­gen erge­ben, die ein inhalt­li­ches Update des Plugins nötig machen wür­den.

Ande­rer­seits hat Revisr über 3.000 akti­ve instal­la­tio­nen und recht sta­bi­le Down­load-Raten. Ein zwei­ter Blick auf ähn­li­che Plugins wie bei­spiels­wei­se Ver­si­onPress kann aber in jedem Fall nicht scha­den.

Voraussetzungen

Der Ser­ver dei­ner Word­Press-Instal­la­ti­on muss Git instal­liert haben. Das ist auch bei vie­len Web­hos­tern der Fall. Wenn Du nicht weißt, ob dein Hos­ter Git-Unter­stüt­zung instal­liert hat, stel­le fol­gen­des php-Script als Datei git-version.php in das root-Ver­zeich­nis dei­nes Word­Press:

<?php
Header('Content-Type: text/plain');
$path = trim(shell_exec('which git'));
if (!$path) {
$path = str_replace('git is ', '', trim(shell_exec('type git')));
}
echo "git path: " . $path . "\n";
$version = shell_exec($path.' --version');
echo "git version: " . $version . "\n";

Wenn Du die­ses Script mit https://wordpress.mydomain.tld/git-version.php auf­rufst, soll­te es etwa fol­gen­de Aus­ga­be erzeu­gen:

git path: /usr/bin/git git
version: git version 2.11.0

In die­sem Fall (mein Web­hos­ter ist Hetz­ner) ist also alles ok.

Installation

Das Plugin kann ganz nor­mal über die Word­Press-GUI aus dem Plugin-Repo­sito­ry instal­liert und akti­viert wer­den. So ist sicher­ge­stellt, dass immer die aktu­el­le Ver­si­on instal­liert ist.

Lokale Konfiguration

Beim ers­ten Auf­ruf des Plugins aus der Menü­leis­te zeigt Revisr einen Dia­kog an, mit ldem man den Git-Cli­ent ent­we­der mit einem exis­tie­ren­den Repo­sito­ry ver­bin­den oder ein neu­es anle­gen kann. Da wir ganz von vorn anfan­gen, erzeu­gen wir also ein neu­es Repo­sito­ry.

Im fol­gen­den Dia­log kann man aus­wäh­len, was Inhalt der Repos wer­den soll. Das ist immer von der eige­nen Arbeits­wei­se abhän­gig. Hier wol­len wir zunächst die gesam­te Instal­la­ti­on abde­cken und las­sen die Stan­dard ein­stel­lun­gen unver­än­dert. Damit wer­den alle Datei­en und Daten­bank-Tabel­len auf­ge­nom­men.

Mit einem ers­ten Com­mit fül­len wir das Repo­sito­ry mit dem aktu­el­len Sta­tus unse­rer Word­Press-Instal­la­ti­on

Remote Konfiguration

Das Repo­sito­ry soll auch auf einem ent­fern­ten Git-Ser­ver gespie­gelt wer­den. Dazu müs­sen wir zunächst her­aus­fin­den, wie der remo­te Ser­ver ange­spro­chen wer­den kann. In mei­nem Fall soll die Ver­bin­dung per ssh zum Gogs-Ser­ver auf­ge­baut wer­den. Ein Benut­zer ist dort ein­ge­rich­tet, ein lee­res Repo­sito­ry eben­so.

Gogs ver­rät die URL des Repo­sito­ry in der Kurz­an­lei­tung, die bei einem lee­ren Repo­sito­ry im Datei­en Tab ange­zeigt wird. Unter Die­ses Repo­sito­ry klo­nen lis­tet es die ent­spre­chen­den URLs für den http- und ssh-Zugriff. Mög­li­cher­wei­se müs­sen Ser­ver­na­me und Port ange­passt wer­den, wenn Gogs hier Anga­ben anzeigt, die nur inner­halb des Docker-Con­tai­ners gül­tig sind.

Zugriff über SSH

In mei­nem Fall sieht die URL für den SSH-Zugriff etwa so aus:

ssh://<user>@<servername>:<port>/~/<userspace>/<repository>.git

Solan­ge die Remo­te URL nicht kor­rekt ist, zeigt Revisr Remo­te not found… neben dem Ein­trag an.

Jetzt müss­te ich noch ein SSH-Key-Paar erzeu­gen und auf dem Web­ser­ver so able­gen, dass Revisr den Key benut­zen kann. Die Anlei­tung beschreibt das aller­dings nur für den Fall, dass man Shell-Zugriff auf den Web­ser­ver hat und den Key im SSH-Agent ein­tra­gen kann.

Ich habe kei­ne Mög­lich­keit gefun­den, den Key auf mei­nem Sha­red Ser­ver ohne Shell-Zugriff für Revisr zugäng­lich zu machen. Somit ist der SSH-Zugriff zum Git-Repo­sito­ry wohl nicht mög­lich.

Zugriff über https

Bleibt der Zugriff über ver­schlüs­sel­tes http. Die Lösung hal­te ich für nicht so sau­ber, da man in der Kon­fi­gu­ra­ti­on das Git-User-Pass­wort im Klar­text in der URL able­gen muss.

Der Gogs-Ser­ver auf dem loka­len Port 3000 ist ohne­hin schon über den rever­se Pro­xy aus dem Inter­net über Port 443 erreich­bar.

Für https sieht die URL, die auf der Revisr-Kon­fi­gu­ra­ti­ons­sei­te unter Revisr Set­tings Remo­te Remo­te URL ein­ge­tra­gen wer­den muss, in etwa so aus:

https://<git-user>:<passwort>@<server>/<git-user>/<repository>.git

Das akzep­tiert Revisr klag­los. Auf dem Revisr-Dash­board kann man jetzt die comit­ted files mit Quick Actions Push Chan­ges auf den remo­te Git-Ser­ver schie­ben. Der ers­te Ver­such endet aller­dings mit die­sem Feh­ler:

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

Nach kur­zem goo­geln fin­det sich die Lösung, in der Kon­fi­gu­ra­ti­on des nginx-Pro­xies die maxi­ma­le Grö­ße des cli­ent body zu erhö­hen. Die fol­gen­der Zei­le in den erwei­ter­ten Optio­nen des rever­se Pro­xy (die Grö­ße von 50m kann noch opti­miert wer­den) behebt das Pro­blem:

client_max_body_size 50m;

Danach funk­tio­niert der push auf den remo­te Ser­ver ohne Pro­ble­me, und das Repo­sito­ry ist im Gogs-Ser­ver sicht­bar.

Arbeit mit Git und Gogs

Für die Ent­wick­lung und Soft­ware­ver­tei­lung wird Revisr auf allen betei­lig­ten Word­Press-Ser­vern instal­liert. Auf dem Ent­wick­lungs­sys­tem befin­den sich die Net­be­ans-IDE inklu­si­ve wei­te­re Ent­wick­lungs­werk­zeu­ge und ein Word­Press-Test-Ser­ver. Hier star­tet die Ent­wick­lung eines neu­en Pro­jekts.

Der aktu­el­le Stand wird mit Net­be­ans direkt auf den Test­ser­ver syn­chro­ni­siert, so dass man sofort tes­ten kann. Das stellt man bei Pro­ject -> Pro­per­ties -> Sources -> mit einem Haken bei Copy files from source fool­der to ano­t­her loca­ti­on und Anga­be des (loka­len) Word­Press-Plugin-Ver­zeich­nis­ses ein.

Wich­ti­ge Ent­wick­lungs­etap­pen und die Release-Kan­di­da­ten wer­den ent­we­der direkt aus Net­be­ans oder vom Test-Ser­ver auf das Git-Repo­sito­ry gespie­gelt.

Der Sta­ging-Ser­ver zieht sich das Repo­sito­ry vom Gogs-Ser­ver. Hier wer­den Tests unter pro­duk­ti­ons­na­hen Bedin­gun­gen und Ein­be­zie­hung von Nut­zern gefah­ren. Klei­ne­re Ände­run­gen kön­nen direkt dort vor­ge­nom­men und zum Repo­sito­ry zurück­ge­spie­gelt wer­den.

Bei grö­ße­ren Ände­run­gen kann man sich den aktu­el­len Stand auf den Test-Ser­ver zurück­spie­geln und mit der Ent­wick­lungs­um­ge­bung bear­bei­ten.

Schließ­lich wird der Pro­duk­ti­ons­ser­ver über Revisr mit dem fer­ti­gen Stand aus Gogs bespielt. Bei uner­war­te­ten Pro­ble­men kann man mit Revisr ohne wei­te­res auf einen älte­ren Stand des Repo­sito­ry zurück­ge­hen.

Bei sehr klei­nen Pro­jek­ten kann der Sta­ging-Ser­ver even­tu­ell ent­fal­len.

Sieht man von der man­gel­haf­ten SSH-Key-Unter­stüt­zung ab, schein sich Revisr gut für die Ent­wick­lungs­ar­beit an Word­Press-Pro­jek­ten zu eig­nen. Wie es sich in der Pra­xis schlägt, wird die Zukunft zei­gen.


Quel­len:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.