Branch-Struktur
Bei größeren Projekten setze ich git nicht nur als Versionierung ein, sondern auch zum deployen der Änderungen. Hierfür setze ich auf folgende Branch-Struktur:
- master
- dev
- v0.0.1
- feature-name_developer-name
- v0.0.2
- v0.0.1
Die Branches haben folgende Bedeutungen:
- master ist der master-Branch. Hierin befindet sich immer der aktuelle Produktiv-Stand.
- dev ist der „Staging“-Branch. Der Stand in diesem Branch unterscheidet sich vom Master. Er wird auf einen eigenen Staging-Server deployed, damit neue fertige Features in einer der Produktivumgebung sehr ähnlichen Umgebung getestet werden können.
- Unter dem dev-Branch finden sich Versions-Branches. Hier wird unterteilt, da nicht jedes Feature für die nächste Version vorgesehen sein muss.
- Unterhalb der Versions-Branches finden sich dann die Feature-Branches. Jeder Entwickler erstellt für das neue Feature an dem er arbeitet einen neuen Branch und bennent diesen entsprechend mit dem Featurenamen und seinem Namen/Kürzel. Je nach Projekt erhalten die Feature-Branches eigene Nummern, die dem Namen vorangestellt werden (z. B. „#0123_…“). Die Nummer entspricht dabei der GitHub-Issue-Nummer.
Ein neuer Branch wird mit folgendem Befehl erstellt:
git checkout -b branch-name
Deployment-Struktur
Um auf einen Server zu deployen gibt es zwei Möglichkeiten.
Webhooks (Github)
Die eine Möglichkeit sind Webhooks. Dabei werden URLs aufgerufen, wenn eine bestimmte Aktion in github ausgelöst wird. Dies kann z. B. sein, wenn in den dev-Branch gemerged wurde. Dies empfiehlt sich jedoch nur für die Staging-Umgebung. Die Produktiv-Umgebung sollte immer manuell deployed werden. Nur so kann im Anschluss korrekt getestet und bei Bedarf sofort reagiert werden. Außerdem muss der betreffende Server aus dem Internet erreicht werden können.
Manueller Pull
Die zweite Möglichkeit sind manuelle Pulls um Änderungen aus dem Branch auf den jeweiligen Server zu „ziehen“.
In beiden Fällen muss es eine geklonte Kopie geben, die dann jeweils aktualisiert wird. Im folgenden Verlauf möchte ich aufzeigen, wie dies eingerichtet wird.
Git Repository auf Server einrichten
- Als erster Schritt muss sichergestellt sein, dass git auch installiert ist. Dies kann mit folgendem Befehl getestet werden:
git --version
Wird die Version ausgegeben und kein Fehler, ist git installiert. Sollte git noch installiert sein, müssen wir dies an dieser Stelle tun.
- Um uns mit dem Github-Server verbinden zu können, benötigen wir entweder Zugangsdaten oder ein Zertifikat. Serverseitig nutze ich lieber Zertifikate, da ich diese unabhängig von den Zugangsdaten tauschen kann, wenn ich möchte. Wie man Zertifikate erstellt beschreibt github in seinem Hilfebeitrag Generating a new SSH key and adding it to the ssh-agent. Die Anleitung muss komplett durchlaufen werden.
- Als nächstes öffnen wir den öffentlichen Schlüssel mit folgendem Befehl:
vi ~/.ssh/id_rsa.pub
Dieser Schlüssel wird gemäß der Anleitung von Github zum Einrichten von Deploy-Keys im Repository auf github.com eingerichtet.
- Nun klonen wir das git-Repository mit folgendem Befehl (bitte den Repo-Link entsprechend anpassen):
git clone git@github.com:<member>/<repository>.git /temp
Dies generiert einen neuen Ordner /temp in dem sich die Dateien aus dem Repository finden.
- Nun verschieben wir die benötigten Dateien in das Stammverzeichnis unseres Projekts. Im Normalfall sind dies alle Dateien (1). Existieren die Dateien bereits auf dem Server wird nur der .git-Ordner benötigt (2).
- Projekte ohne existierende Dateien
Wenn der Ordner unseres Projektes noch keine Projekt-Dateien enthält (z. B. bei einem neuen Projekt), verschieben wir alle Dateien mit folgenden Befehlen:mv /temp/.[!.]* ./
- Projekt mit bereits existierenden Dateien
In einigen Fällen kann es sein, dass Dateien bereits existieren, z. B. weil das Projekt auf einen bestehenden Projekt beruht und nicht von Anfang mit git gearbeitet wurde. In diesem Fall kopieren wir nur den .git-Ordner und löschen den temp-Ordner:mv /temp/.git ./.git rm -rf /temp
- Projekte ohne existierende Dateien
- Wenn wir uns auf dem Staging-Server befinden, müssen wir bevor wir die Dateien holen in den dev-Branch wechseln:
git checkout -b dev
- Nachdem nun der Ordner initalisiert ist laden wir den aktuellen Stand aus dem Repository. In den meisten Fällen kommt hier nur die Antwort „Already up-to-date“, womit wird aber wissen, dass die Verbindung erfolgreich war.
git pull
- Im Anschluss können wir uns noch mit „git status“ den aktuellen Status anzeigen. Wenn hierbei geänderte Dateien angezeigt werden, sollten wir uns den aktuellen Stand der Dateien vom Server auf Zwang herunterladen. Dies machen wir mit dem folgenden Befehl:
git reset --hard
Achtung: Damit werden die angegebenen Dateien mit dem Stand im git überschrieben.
- Nun ist unser Server fertig eingerichtet. Verwendet man Framework wie Laravel muss dieses noch eingerichtet werden (z. B. .env-Datei erstellen und konfigurieren und „composer update“ ausführen).
Projekt aus git-Repository aktualisieren
Um das Projekt nun auf den Server zu deployen nutzen wir jedes Mal einfach den folgenden kurzen Befehl:
git pull
Je nach Anwendung müssen im Anschluss noch Update-Befehle ausgeführt werden. Nutzt man z. B. Laravel dann wären dies:
composer update php artisan migrate
Neueste Artikel von Bernhard Krämer (alle ansehen)
- Terrform AWS Fehler: „Error: collecting instance settings: UnauthorizedOperation: You are not authorized to perform this operation.“ - 3. August 2023
- Terraform AWS Fehler „Error: reading EC2 Instance (…): reading block devices: UnauthorizedOperation: You are not authorized to perform this operation. - 3. August 2023
- Was Google über dich weiß… - 25. April 2019