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

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

  1. 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.

  2. 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.
  3. 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.

  4. 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.

  5. 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).
    1. 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/.[!.]* ./
    2. 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
  6. 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
  7. 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
  8. 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.

  9. 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

 

The following two tabs change content below.
Bernhard Krämer
entwickelt Webseiten und Webanwendungen vorwiegend auf Basis von PHP/MySQL und führt für Unternehmen Security-Awareness-Kampagnen durch. In diesem Blog schreibt er über diverse Themen rund um Webentwicklung, das Internet und dessen sichere Anwendung.