Updates mit Git
In den meisten Fällen ist es sinnvoll Updates und andere Änderungen zuerst in einer Testinstanz zu prüfen, bevor die Produktivinstanz aktualisiert wird. Mit Git gibt es dafür eine Reihe von Möglichkeiten.
Nehmen wir an eine OPUS 4 Instanz wurde mit Git installiert und eingerichtet. Diese Instanz ist im produktiven Einsatz. Im folgenden wird sie Prod genannt.
Es wird angenommen das Prod im Verzeichnis /var/local/opus4/opus4-prod
installiert wurde.
Testinstanz anlegen
Damit Änderungen in Prod nicht sofort Live für alle Nutzer sichtbar sind, insbesondere, wenn etwas schief geht oder länger dauert, sollte man vorher alles in einer Testinstanz prüfen. Dazu kann ein Clone von Prod angelegt werden.
Durch dieses Kommando wird das gesamte Git Repository kopiert. Dateien, die nicht unter Versionskontrolle sind, werden
nicht übertragen. Das könnten z.B. lokale Konfigurationsdateien wie config.ini
sein.
Lokale Konfigurationsdateien können natürlich auch mit Git versioniert werden. Man muss dann aber unbedingt aufpassen, daß später bei einem *Push* diese Dateien nicht letztendlich mit auf GitHub landen, insbesondere wenn sie Passwörter enthalten sollten. Das betrifft aber eigentlich nur Instanzen, die sich an der Entwicklung von OPUS 4 beteiligen wollen und daher auch Dateien zurück zu GitHub übertragen.
Die Testinstanz kann jetzt mit Datenbank, Suchindex und URL eingerichtet werden. Ob dabei die Informationen der Prod Instanz verwendet werden oder nicht hängt von verschiedenen Faktoren ab. Es kann nützlich sein, die echten Daten in der Testinstanz zu sehen, aber dann muss aufgepasst werden, daß diese Daten nicht versehentlich verändert werden.
Das neue Repository merkt sich, wo die Dateien her gekommen sind.
In unserm Beispiel würde die Ausgabe so aussehen.
Dateien ändern/hinzufügen
In der Instanz Test können nur Änderungen an Dateien vorgenommen werden, z.B. am Layout oder den Dokumenttypen. Mit
git status
bekommt man angezeigt welche Dateien lokal verändert wurden. Am Anfang sollte die Ausgabe so aussehen.
Zur Zeit könnte der verwendete Branch evtl. solrupdate anstelle von master sein.
Als lokale Änderung könnte zum Beispiel eine Übersetzung angepasst werden. TODO Details
Mit status
wird diese neue Datei aufgelistet.
Mit dem add
Kommando kann die Datei zum nächsten Commit hinzugefügt werden.
Mit commit
wird die neue Datei dann in die Versionskontrolle aufgenommen.
Mit status
kann der aktuelle Zustand des Repositories für die Test Instanz wieder angezeigt werdne.
Die Test Instanz ist jetzt einen Commit weiter als die Produktivinstanz.
Änderungen übertragen
Wenn die Änderungen in der Test Instanz geprüft wurden können sie in die Produktivinstanz übertragen werden. Dafür
wird in Git normalerweise das push
Kommando verwendet. In unserem Fall ist das Prod Repository aber nicht bare
(TODO verlink Erläuterungen). Das heißt ein Push wird von Git normalerweise abgelehnt. Eine Installationsvariante mit
bare Repository wird später besprochen.
Um die Änderungen jetzt von der Test in die Prod Instanz übertragen zu können fügen wir die Testinstanz als Remote zu Produktivinstanz hinzu.
Nun können die Änderungen mit pull
anstelle von push
übertragen werden. Im Verzeichnis der Prod Instanz wird
folgendes Kommando ausgeführt.
Dadurch wird die gerade in der Testinstanz angelegte Datei in die Produktivinstanz übertragen.