Kivitendo Installationen mit git verwalten: Unterschied zwischen den Versionen

Aus revampedia
Zeile 65: Zeile 65:
 
git branch -a
 
git branch -a
  
 +
Branch auswählen, z.B. design_4.0-rebase-3.5.4+
  
 +
Lokalen Branch als Kopie des Branches auf github erstellen:
 +
 +
git checkout -b design_4.0-rebase-3.5.4+ origin/design_4.0-rebase-3.5.4+
 +
 +
== Aktualisieren eines lokalen Branches, dessen Original durch ein Rebase verändert wurde ==
 +
 +
git reset --hard origin/design_4.0-rebase-3.5.4+
  
 
[[Kategorie:Kivitendo]]
 
[[Kategorie:Kivitendo]]

Version vom 13. Oktober 2019, 15:14 Uhr

Voraussetzungen: Linux Installation (z.B. Debian Jessie) mit git und allen für kivitendo benötigten Paketen (siehe kivitendo Dokumentation), Webserver- und Postgres-Konfiguration gemäss kivitendo Dokumentation.

Neue kivitendo Installation mit git einrichten

mkdir /var/www/kivitendo/firma

cd /var/www/kivitendo/firma

git clone https://github.com/kivitendo/kivitendo-erp.git

(Dadurch wird ein Unterverzeichnis /var/www/kivitendo/firma/kivitendo-erp erzeugt und darin die gesamte kivitendo-Installation inkl. einem unsichtbaren Unterordner /var/www/kivitendo/firma/kivitendo-erp/.git für die git-Versionsverwaltung.

cd kivitendo-erp

git tag

(zeigt die vorhandenen releases an)

git checkout -b produktiv release-3.4.0

(erstellt den neuen Branch "produktiv" mit allen Änderungen bis und mit dem gewünschten Release, in diesem Beispiel release-3.4.0)

Eventuelle nach dem Release erstellte wichtige Bugfixes installieren:

git cherry-pick commit-Bezeichnung

Konfigurationsdatei erstellen:

cd config

cp kivitendo.conf.default kivitendo.conf

kivitendo.conf editieren und anpassen

Damit ist die Installation auf dem Server abgeschlossen und alles weitere kann über den Aufruf der Web-Administration eingerichtet werden.

Upgrade auf neues Release

Wichtig: Backup der Datenbank(en) erstellen !!

git checkout master

(wechselt zum master-Branch)

git pull

(fügt dem lokalen master-Branch alle Änderungen aus dem master Branch im github-Repository hinzu)

git checkout produktiv

(wechselt wieder zum Branch produktiv)

git merge release 3.4.1

(erweitert den Branch produktiv auf das gewünschte Release, in diesem Beispiel release 3.4.1)

Anschliessend zunächst einmal im Administrations-Interface einloggen und anschliessend im normalen Benutzer-Weblogin. Falls Datenbank Upgrades nötig sind, werden diese nun ausgeführt.
(Achtung: sobald ein Datenbankupgrade durchgeführt wurde, ist es nur möglich, mit git wieder zu einem Zustand vor dem Datenbankupgrade zurückzukehren, wenn die Datenbank aus dem vorher erstellten Backup zurückgespielt wurde.)

Verwenden eines anderen Branches aus dem github-Repository

Alle auf github vorhandenen Branches anzeigen:

git branch -a

Branch auswählen, z.B. design_4.0-rebase-3.5.4+

Lokalen Branch als Kopie des Branches auf github erstellen:

git checkout -b design_4.0-rebase-3.5.4+ origin/design_4.0-rebase-3.5.4+

Aktualisieren eines lokalen Branches, dessen Original durch ein Rebase verändert wurde

git reset --hard origin/design_4.0-rebase-3.5.4+