In diesem Hilfeartikel geht es um grundsätzliche Konzepte von Git und zur Arbeit mit in der speziellen Fortrabbit WebHosting Deployment Lösung. Die Einstellungen, die im MISH Interface unter der dem Webprojekt gemacht werden können sind, sind bei der Webprojekt Hilfe selber beschrieben.
Versionsverwaltung oder englisch VCS (Version Control System) "ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird" (Quelle: Wikipedia).
Eine Versionsverwaltung im Softwareumfeld ist eine Methode um Änderungen an Quelltexten mit Zeitstempel und Benutzerkennung zu erfassen. Weiterhin können verschiedene Entwicklungszweige (Branches) verwaltet werden, in denen verschiedene Versionen parallel weiterentwickelt werden können. Diese Zweige können später wieder zusammengeführt werden. Zudem gibt es benannte Versionsstände (Tags) auf die später wieder zugegriffen werden kann.
Git ist eine verteilte Versionsverwaltung, initial entwickelt von Linus Torvalds, dem Autor von Linux. Im Gegensatz zu Mercurial ist es komplett in der Sprache C geschrieben, was einen nicht unerheblichen Geschwindigkeitsvorteil mit sich bringt.
Deployment ist unsere spezielle Lösung, eine Zusatzoption für ein neues Webprojekt. Es ist eine spezielle Webentwicklungsumgebung, die Git Repository Hosting und WebHosting miteinander vereint. Es ist allerdings nicht zwingend notwendig mit Git zu arbeiten, um Deployment zu nutzen, ein Workflow nur mit FTP ist auch denkbar, aber lesen Sie selbst:
Ein Webprojekt mit Deplyoment wird intern in ein Git Repository, einen virtuellen master- und einen virtuellen live-Client aufgeteilt. Wann immer ein "git push" ausgeführt wird und eine Änderungen in einer Branch (master oder live) erkannt wird, ziehen sich die entsprechenden virtuellen Clients automatisch ein update ihrer Branch. Danach wird das Client Verzeichnis per rsync in die jeweilige Umgebung (Staging oder Production) synchronisiert. Bei dieser Synchronisierung werden ausgeschlossen Verzeichnisse nicht übertragen. Alle anderen werden vollsynchronisiert, d.h. Dateien/Verzeichnisse die nicht in Git liegen werden gelöscht, neue werden angelegt, vorhandene überspielt.
Die Arbeitsweise (engl: Workflow) mit einer Versionsverwaltung in einer Webhosting Umgebung unterscheidet sich stark vom klassischen arbeiten mit FTP/WebDAV/SCP.
Prinzipiell gibt es hier keine allgemein anerkannte Best-Practice. Jede größere Website, die von mehr als einem Entwickler implementiert wird, hat ihre eigenen Eigenarten und daraus resultierenden Notwendigkeiten. Wir haben uns daher entschlossen eine möglichst flexible Arbeitsweise vorzugeben, mit der man, nach unserer Erfahrung, sehr gut bei kleinen bis großen Projekten im WebHosting Berreich fährt.
Kurz gesagt lässt sich dieser Workflow in mit zwei Begriffen beschreiben: Staging und Production.
Staging ist die Entwicklungsumgebung. Sie wird auf extra zur Verfügung gestellten reinen Staging-HTTP-Servern realisiert. Es gibt eine eigene Subdomain für Staging-Umgebung des Webprojektes (es können auch eigene hinzugefügt werden). Angedacht ist hier, dass hier neuer Code ausführlich getestet werden kann. Programmierfehler und Performanceprobleme können so, ohne dass ein Website-Besucher jemals davon erfährt, vorab gefunden und gefixt werden.
Production ist die Live-Umgebung, das was der Seitenbesucher sieht. Hier sollte immer stabiler Code laufen, da Fehler schon im Staging aussortiert wurden.
Das tatsächliche Arbeiten wird über Branches in Git realisiert. Hierfür werden zwei benannte Branches vorangelegt: "master" für die Staging-Umgebung und "live" für Production. Wann immer eine Synchronisierung der lokalen Daten mit dem Server-Repository erfolgt (git push), erfolgt ein automatisches Synchronisieren auf die jeweilige Umgebung (Deployment). Der Workflow sieht hier also vor, dass Änderungen und Updates zuerst in die master branch eingespielt und dann getestet werden, bis alle Fehler ausgemerzt sind. Danach erfolgt eine Zusammenführung (git merge) der master in die live Branch, was dann eine Veröffentlichung in die Production Umgebung bewirkt.
SSH ist ein sicheres, verschlüsseltes Protokoll mit dem man Netzwerkverbindungen über unsichere Netze (z.B. das Internet) aufbauen kann. Git selber kann keine Verschlüsselung, kann aber sein eigenes Protokoll in SSH einbetten, so dass alle Aktionen komplett abgesichert durchgeführt werden können. Es gibt verschiedene Wege zur Absicherung von SSH Verbindungen. Vereinfacht: man kann entweder eine Passwort-Authentifizierung verwenden oder das sogenannten Public-Key-Verfahren. Letzteres ist deutlich sicherer, da es viel bessere gegen Brute-Force Attacken und schluderige Admins geschützt ist.
Das ist je nach verwendetem Betriebssystem unterschiedlich. Einen großartigen Schritt-für-Schritt Guide gibt es auf github:
Hier zeigen wir, wie man auf Kommandozeilenebene (Terminal, Shell) mit unserem Deployment und Git arbeitet. Die Methoden und Aufrufe können abhängig vom Betriebsystem abweichen.
Wie immer gibt es mehrere Wege, hier der einfachste. Dafür muss man erst mal eine Konsole öffnen. Unter Mac heißt das Programm dafür "Terminal.app", unter Linux "gnome-terminal", "kterm" oder "xterm", je nachdem unter welcher X-Oberfläche man arbeitet.
1. Ins .ssh Verzeichnis des Users wechseln
$ cd $HOME/.ssh
2. Nun sollte man prüfen ob schon ein Schlüssel vorhanden ist:
$ ls
Liegt hier eine id_rsa Datei, dann ist schon ein Schlüssel da. Dieser kann dann entweder genutzt werden, oder es kann ein neuer erstellt werden. Für letzteres oder sollte man den alten Schlüssel in jedem Falle sichern:
$ mkdir backup $ cp id_rsa* backup/
Wurde der alte Schlüssel gesichert oder war noch keiner vorhanden, kann so ein neues Schlüsselpaar erstellt werden:
$ ssh-keygen -t "rsa" -C "meine@email.tld"
Nach dem letzten Schritt werden zwei Dateien "./ssh/id_rsa" und "./ssh/id_rsa.pub" erstellt. Erstere ist der so genannten Private-Key und letztere der Public-Key. Was auch immer passiert, nie den privaten Schlüssel aus ".ssh/id_rsa"-Datei an Dritte weitergeben!
Der Inhalt des öffentlichen Schlüssels aus der Datei "./ssh/id_rsa.pub" kann nun in MISH als hinzugefügt werden. Am einfachsten gibt man den Inhalt dafür auf der Konsole aus und kopiert ihn:
$ cat id_rsa.pub
Ist das Webprojekt angelegt und der eigene öffentliche Schlüssel in MISH installiert kann es auch schon los gehen. Dafür muss man sich als erstes die aktuelle Kopie des Webprojektes ziehen. Unter Git nennt man diesen Vorgang klonen. Auf der Konsole:
$ cd mein-projekt-verzeichnis $ git clone git@deployment.service.frbit.de:/web123.git .
Wobei web123.git entsprechend dem Namen des Webprojektes angepasst werden muss.
Hat alles geklappt findet man nun drei Unterverzeichnisse "www", "libs" und "cgi-bin" in seinem Projektverzeichnis (plus ein Verstecktes ".git", unter Umständen existieren "libs" und "cgi-bin" auch noch nicht, da sie leer sind und Git leere Verzeichnisse nicht kennt).
Da mit zwei Deployements über je eine git-Branch gearbeitet wird und der erste clone-Vorgang nur die master-Branch herunter geladen hat muss nun noch die live-Branch ausgecheckt werden:
$ git checkout -b live origin/live $ git checkout master
Der erste Checkout legt die live branch lokal an und erstellt gleichzeitig eine origin-Beziehung ("Tracking") mit der live-Branch auf dem Server. Der zweite checkout wechselt wieder zurück zur master-Branch.
Erst einmal muss man sich versichern, dass bei Git die "master" Branch gewählt ist, welche in die Staging Umgebung deployt wird. Das geht so:
$ git branch live * master
Wichtig ist hier das Sternchen ("*") vor master. Ist es vor live, dann muss nun zurück in die master-Branch gewechselt werden:
$ git checkout master
Nun kann ins www Verzeichnis gewechselt werden und die erste Datei hinzugefügt werden.
$ cd www
Nun einfach eine neue Datei mit einem Texteditor erstellen. Diese kann dann z.B. test.html genannt werden. Als nächstes muss die Datei Git bekannt und hinzugefügt werden. Dies geht mit dem "add" Kommando:
$ git add test.html
Damit ist die Datei aber erst einmal markiert worden und muss nun noch in die lokale Revisionsverwaltung eingespielt werden:
$ git commit -a -m "Meine erste Datei"
Ist das auch erledigt kann entweder weiter fleißig an Dateien gearbeitet werden oder wir können die neue Datei in die Staging Umgebung veröffentlichen:
$ git push
Das war es auch schon. Die index.html sollte nun unter http://web123.staging.frbit.de/test.html aufrufbar sein (URL entsprechend dem Webprojektnamen ändern).
Dazu wird die so merge-Methode von Git genutzt. Bevor wir dies machen, erst noch einmal versichern, dass wir in der richtigen branch sind und dass alle lokalen Änderungen eingespielt sind:
$ git branch live * master
Die "master" Branch sollte das Sternchen haben.
$ git commit -am 'Alle Änderungen'
Nun sind wir auf jeden Fall aktuell
$ git checkout live
Damit wurde in die "live" branch gewechselt, was wiederum mit "git branch" nachvollzogen werden kann (Sternchen bei live). Nun fügen wir die Änderungen aus "master" in "live" ein:
$ git merge master
.. und veröffentlichen die Daten in der Production Umgebung
$ git push
Das war es auch schon. Nun sollte nicht vergessen werden wieder in die "master" branch zurück zu wechseln, sonst gehen die nächsten Änderungen versehentlich gleich in Production.
$ git checkout master
Wie vorsichtig man auch ist: irren ist menschlich und der eine oder andere Fehler wird immer erst zu spät bemerkt. Natürlich muss dieser dringend und sofort behoben werden. Hat man aber grade ein paar offenen Fäden in Staging und kann diese nicht schnell mal schliessen um den Fehler in der Live-Umgebung zu beheben, dann bietet es sich an eine weitere Branch anzulegen. Diese sollte als Klon aus der live branch (hier ist der Fehler) angelegt werden.
$ git checkout live $ git checkout -b hotfix-2011-11-11
Nun kann man hier den Fehler beheben. Im Idealfall kann man den Patch sogar vorab in Staging testen (nicht Ideafall = am gleichen Code wird derzeit in Staging gearbeitet):
$ git checkout master $ git merge hotfix-2011-11-11 $ git push
Ist der Patch getestet und funktioniert kann die ganze Branch in Production eingespielt werden:
$ git checkout live $ git merge hotfix-2011-11-11 $ git push
Theoretisch kann man auch auf die hotfix Branch verzichten und die Änderungen direkt in live einspielen, aber so lässt sich später einfacher nachvollziehen wann und von wem / wann / was / wie gefixt wurde.
# Klonen des Repositories
$ git clone git@deployment.service.frbit.de:/web123.git .
Cloning into ....
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4/4), done.
# Alle Branches anzeigen
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/live
remotes/origin/master
# Checkout und Tracking der live-Branch
$ git checkout -b live origin/live
Branch live set up to track remote branch live from origin.
Switched to a new branch 'live'
# Wo sind wir ?
$ git branch
* live
master
# Zurück zur master-Branch
$ git checkout master
Switched to branch 'master'
# Wo sind wir ?
$ git branch
live
* master
# Erste Änderung
$ echo testdas > www/somefile.txt
# Datei in Git einfügen
$ git add -Av;
add 'www/somefile.txt'
# Erstes Commit einspielen
$ git commit -am 'Erstes Commit'
[master 43616f9] Erstes Commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 www/somefile.txt
# Pushen und damit in Staging-Umgebung deployen
$ git push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 334 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Branch 'master' has been deployed into Staging.
To git@deployment.service.frbit.de:/web123.git
07b5cfa..bc7a6d7 master -> master
# Check ob online
$ curl http://web123.staging.frbit.de/somefile.txt
testdas
# In die live-Branch wechseln
$ git checkout live
Switched to branch 'live'
# Prüfen ob wir wirklich da sind
$ git branch
* live
master
# master-Branch in live-Branch einfügen
$ git merge master
Updating 07b5cfa..bc7a6d7
Fast-forward
www/somefile.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 www/somefile.txt
# Pushen der live-Branch und damit Deployment auf Production Umgebung
$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: Branch 'live' has been deployed into Production.
To git@deployment.service.frbit.de:/web123.git
07b5cfa..bc7a6d7 live -> live
# Prüfen ob es geklappt hat
$ curl http://web123.test.frbit.de/somefile.txt
testdas
# Und wieder zurück in die master-Branch
$ git checkout master
Switched to branch 'master'
# Was ist passiert ?
$ git log
commit bc7a6d75097fa29a77948581bc07f48977584777
Author: Ulrich Kautz <uk@fortrabbit.de>
Date: Mon Apr 4 21:03:35 2011 +0200
Erstes Commit
commit 07b5cfae2b476dfb8c2baedc72376de8a237c054
Author: Automated Git <info@fortrabbit.de>
Date: Mon Apr 4 20:56:14 2011 +0200
init-from-live
# So sieht die .git/config Datei aus
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@deployment.service.frbit.de:/web123.git
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "live"]
remote = origin
merge = refs/heads/live
Wer nicht auf der Shell zuhause ist, muss nicht auf Git verzichten, es gibt eine Vielzahl von grafischen Git Interfaces, die helfen die Prozesse zu visualisieren. Vor allem bei der Arbeit mit Branches kann das recht hilfreich sein. Natürlich gibt es auch hier kommerzielle und lizenzfreie Ansätze. Einige Texteditoren, wie Eclipse und Textmate, bringen von Hause aus Unterstützung mit, andere lassen sicher per Plugin updaten.
Sollte die Website interaktive Datei-Inhalte haben, also Dateien, die zur Laufzeit vom Benutzer erstellt/geändert werden können (oder die sonstwie zur Laufzeit Dateien erzeugt werden), dann müssen die Verzeichnisse in denen diese Dateien abgespeichert werden von der Versionsverwaltung ausgeschlossen werden. Wird das nicht gemacht, dann werden die Daten (Dateien/Verzeichnisse) beim nächsten synchronisieren gelöscht. Der Check, ob ein Ausschlussverzeichnis existiert bezieht sich auf die live-Branch. Wenn man ein Ausschlussverzeichnis per Git anlegen möchte sollte man darauf achten, dass es einen Inhalt (irgendeine Datei) hat, da leere Verzeichnisse von Git ignoriert werden.
".gitignore" funktioniert zwar "lokal", d.h. damit ausgeschlossene Pfade werden auch nicht eingespielt, aber das hat noch keine Auswirkung auf die Synchronisierung! Derzeit wird noch überlegt ob .gitignore zusätzlich zugelassen wird, aber Sicherheitserwägungen (jeder Entwickler kann maßgeblich Schaden anrichten, indem er aus Versehen ein Ausschluss löscht / ändert) überwiegen bisher noch die Geschwindigkeit (geht schneller als ins Interface zu wechseln - aber: wie häufig ändert man hier etwas?).
Prinzipiell kann man ohne weiteres per FTP auf ein Webprojekt mit Deployment zugreifen. Dabei ist aber zu bedenken, dass hier gemachte Änderungen (sofern nicht innerhalb eines Ausschlussverzeichnisses) beim nächsten "git push" Vorgang überschrieben beziehungsweise gelöscht werden. Es bietet sich aber an, wenn ein großes Medienverzeichnis hochgeladen werden soll. Dieses sollte dann aber natürlich nicht Teil der Versionsverwaltung sein und von diesem ausgeschlossen werden.
Die Staging Umgebung befindet sich in den Unterverzeichnissen des "staging"-Verzeichnisses innerhalb des Webprojekts:
/www <- Production Daten /staging/www <- Staging Daten
Es ist möglich die jeweilige Umgebung zurück in eine Branch zu synchroniseren. Also anstatt (wie bei enem "git push"-Vorgang) zB die master-Branch in das Staging-Deployment einzupielen kann man so das Staging-Deployment zurück in die master-Branch spielen. Anwendungsszenario ist zB CMS-Upgrades oder ähnliches.
Das Interface für die Re-Synchronisierung findet man in MISH beim Webprojekt. Die URL für das Interface kann auch an Entwickler weitergegeben werden, die keinen Zugang zu MISH haben (sie kann jederzeit resettet werden). Auch gibt es die Möglichkeit den Re-Synchronisations-Vorgang direkt in die eigene Applikation via HTTP Request zu intergrieren.
Git ist nicht geeignet besonders große Dateien zu verwalten. Zudem belegt jede Datei aus Git in einem Webprojekt mit Deployment bis zu 5 mal soviel Speicher wie sie eigentlich groß ist (1 x Staging, 1 x Production, 1 x master Client, 1 x live Client, 1 x Git). Daher sollten allen besonders großen Dateien (oder besser und wenn möglich: alle Binärdateien) möglichst in ausgeschlossene Verzeichnisse gelegt werden, die dann per FTP bespielt werden. Einzelne Dateien die größer als 10MB sind nicht erlaubt - sie werden nicht synchronisiert.
Es werden nur die Verzeichnisse "www", "cgi-bin" und "libs" synchronisiert. Erstellt man darüber hinaus eigene Verzeichnisse auf diesem Level, dann werden diese beim synchronisieren ignoriert, können aber im Git Repository liegen. Dies erlaubt einem z.B. interne Dokumentationen nur im Git zu haben, aber niemals in irgend einer (Staging / Production) Umgebung.
Es kann sein, dass nicht jedes Verzeichnis (www, cgi-bin oder libs) nach dem clone-Vorgang vorhanden ist. Dies liegt daran, dass Git auf Dateibene arbeitet und leere Verzeichnisse "nicht kennt". In diesem Fall kann man das entsprechende Verzeichnis einfach lokal anlegen, mit Dateien bespielen und via git veröffentlichen.
Bei kleineren Projekten mag es ausreichen mit einer einzelnen Umgebung (Production) zu arbeiten. Der Vorteil gegenüber einem Webprojekt ohne Deployment liegt darin, dass man noch ein Logging über alle Änderungen hat und auch schnell zu vorherigen Punkten (Tags) zurückwechseln kann. Prinzipiell raten wir davon aber eher ab, da der größte Vorteil, die Staging/Testing Umgebung, in welcher vorab Code getestet werden kann, nicht genutzt wird.
Hier wird angeraten sich eine weitere MySQL Datenbank anzulegen und diese ausschließlich für die Staging Umgebung zu nutzen. Welche Datenbank genutzt wird, muss auf Applikationsebene implementiert werden. Zur Unterscheidung bieten sich hier vor allem der Pfadname ($_SERVER[ "DOCUMENT_ROOT" ]) oder der Host-Request-Header ($_SERVER[ "HTTP_HOST" ]) an.
In der Staging Umgebung ist PHP mit weniger Prozessen grundsätzlich aktiviert, auch wenn für die Production Umgebung (noch) kein PHP gewählt wurde. APC ist aktiviert. Alle PHP Einstellungen, wie z.B. die PHP Version, gelten für beide Umgebungen (Staging und Production). Wenn in Production nocb kein PHP gewählt ist, wird PHP 5.3 genutzt.
Domains oder Subdomains, die über Fortrabbit registriert sind, können direkt auf eine Umgebung (Production oder Staging) eines Webprojektes mit Deployment geroutet werden. So kann man zB domain.tld auf die Production Umgebung und dev.domain.tld auf die Staging Umgebung zeigen lassen. Wenn man ein Webprojekt mit Deployment als Ziel einer Domain oder einer Subdomain angibt, wird eine enstpechende Auswahl zur Verfügung gestellt. Auch Domains bei anderen Providern können auf beide Umgebungen eines Webprojektes geroutet werden, siehe auch hier.
Ja, prinzipiell schon. Dafür sollte man Branches außer live und master verwenden. Unser Webprojekt mit Deplyoment ist in erster Linie für Teams geeignet die auch gleichzeitig ihre Website bei uns laufen lassen.
Ja, symbolische Links (Symlinks) sind erlaubt. Allerdings dürfen Symlinks nicht außerhalb der Verzeichnisse zeigen. Angenommen es gibt folgende Struktur:
../www/ ../www/datei1 ../www/unterverzeichnis/ ../www/unterverzeichnis/datei2 ../libs/ ../libs/datei3
Dann ist folgendes erlaubt:
../www/link1 -> ../www/datei1 ../www/link2 -> ../www/unterverzeichnis ../www/link3 -> ../www/unterverzeichnis/datei2 ../libs/link4 -> ../libs/datei3
Nicht erlaubt ist alles andere, zum Beispiel:
../www/link1 -> /etc/hosts ../www/link2 -> ../libs/datei3
Nicht erlaubte Links werden nicht synchronisiert, auch wenn Sie im Git Repository sind.
Nein, das geht derzeit nicht.
Ja das geht. Dafür einfach den gleichen öffentlichen Schlüssel eintragen.
Das geht auch. Ein neuer SSH Schlüssle kann wie folg angelegt werden:
$ cd ~/.ssh $ ssh-keygen -t rsa -f neuer-schluessel-web123 -C 'web123'
Danach muss der Schlüssel beim Webprojekt im "Versionsverwaltung"-Tab eingetragen werden.
Es bietet sich an einen Eintrag in die eigene SSH-Konfigurationsdatei vorzunehmen (/home/meinuser/.ssh/config):
Host git-web123 Hostname deployment.service.frbit.de User git IdentityFile /home/meinuser/.ssh/neuer-schluessel-web123 IdentitiesOnly yes
Danach kann, anstatt git@deployment.service.frbit.de, direkt der Host aus der ssh-Konfiguration verwendet werden:
$ git clone git-web123:/web123.git /lokales/verzeichnis/
Dafür muss man erst einmal die Revisionsnummer kennen (oder den Tag, falls mit Tags gearbeitet wurde). Ist die Revisionsnummer oder der Tag bekannt, dann muss man lokal einen harten Reset auf diese Revision durchführen:
$ git reset --hard REVISIONSNUMMER_ODER_TAG
Danach kann push auf das MISH Repository durchgeführt werden. Dieser muss allerdings erzwungen werden (force):
$ git push --force
$ echo "Version 1" > version $ git add version $ git commit -am 'Version 1' $ git tag v1 $ git push
Dann ein paar Aenderungen später
$ echo "Version 33" > version $ git commit -am 'Version 33' $ git tag v33 $ git push
Nun zurück stellen auf Version 12:
$ git reset --hard v12 $ git push --force
Und Version 12 ist wieder online (in der derzeitigen Branch).
Derzeit wird dies nicht nativ angeboten. Was aber moeglich ist: Arbeiten mit 2 Webprojekten a 2 Deployments, so stehen effektiv 4 Deployments zur Verfuegung.
Natürlich gibt es auch hier wieder viele Möglickeiten das Ziel zu erreichen und Notwendigkeiten die die Struktur anders bedingen. Auch kann man zum Beispiel einem zweiten Team, dass ein spezielles Feature imlementiert, so (zeitweise) ein eigenes, zusätzliches 2 Level Deployment zur Verfügung stellen. Nur der Projektleiter hat dann zum Beispiel Zugriff auf beide Repositories und kann die Teamarbeit dann in das "Haupt" Repository mergen.
Klonen des "Haupt" Webprojektes, in dem spaeter die Production Website läuft:
$ cd mein-projekt-verzeichnis $ git clone git@deployment.service.frbit.de:/web123.git .
Auschecken und tracken der "live" Branch
$ git checkout -b live origin/live
Nun umbenennen der lokalen "master" Branch in "testing", damit es ingesamt sauberer wird:
$ git branch -m master testing
Hinzufuegen des zweiten Webprojektes als weiteres entferntes Repository (unter Git als "remote" bekannt):
$ git remote add second git@deployment.service.frbit.de:/web124.git
(Wobei web124.git durch das zweite Webprojekt ersetzt werden muss)
Danach müssen erst einmal alle neuens Branches aus dem Remote "second" geladen werden
$ git fetch second
Hinzufuegen und tracken der live-Branch des zweiten Repositories als lokale "staging" Branch.
$ git checkout -b staging second/live
Hinzufuegen und tracken der master-Branch des zweiten Repositories als lokale "nightly" Branch.
$ git checkout -b nightly second/master
Als letztes muss (bzw kann) noch ein configurations Parameter gesetzt werden, der bestimmt, dass das Tracking nicht nur für pull, sondern auch für push:
$ git config push.default tracking
(So spart man sich länger push Befehle wie git push second nightly:master)
Am Ende sollte das ganze so aussehen
$ git branch -a live * nightly staging testing remotes/origin/HEAD -> origin/master remotes/origin/live remotes/origin/master remotes/second/live remotes/second/master
Und die .git/config Datei sieht so aus:
$ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git@deployment.service.frbit.de:/web123.git [branch "testing"] remote = origin merge = refs/heads/master [branch "live"] remote = origin merge = refs/heads/live [remote "second"] url = git@deployment.service.frbit.de:/web124.git fetch = +refs/heads/*:refs/remotes/second/* [branch "staging"] remote = second merge = refs/heads/live [branch "nightly"] remote = second merge = refs/heads/master [push] default = tracking
Da die Staging-Deployments der beiden Webprojekte web123 und web124 auf extra Staging-Webservern liegen, sollte nun der Deployment Zyklus entsprechend vorgenommen werden:
| Remote Repository & Branch | Lokale Branch | Deployment | Nutzen |
|---|---|---|---|
| web123/live | live | Production | Die Website selber, live und sichtbar für alle Nutzer |
| web124/live | staging | Staging | Hier wird nicht entwickelt, aber geprueft ob alles korrekt funktioniert. |
| web123/master | testing | Testing | Hier koennen Fixes und non-destruktive Änderungen (zB CSS, HTML) eingespielt werden und es werden vorerst abgeschlossenene Entwicklung zum Prüfen eingespielt werden. |
| web124/master | nightly | Nightly | Entwickler können alles ausprobieren, auch große oder integrale Änderungen, die das Potential haben die ganze Website (also dieses Deployment) temporär lahm zu legen. |
Der Zyklus ist also: Nightly -> Testing -> Staging -> Production
# in nightly branch wechseln, denn hier finden die Änderungen statt $ git checkout nightly # Änderung einspielen und auf Nightly-Deployment veröffenlichen $ echo "This is changeset 1" > www/changeset $ git add -Av $ git commit -am "Changeset 1" $ git push # Prüfen der Änderungen $ curl http://web124.staging.frbit.de/changeset This is changeset 1 # Ein Level höher: Änderungen in "testing" Branch übernehmen und auf Testing-Deployment veröffentlichen $ git checkout testing $ git merge nightly $ git push # Prüfen der Änderungen $ curl http://web123.staging.frbit.de/changeset This is changeset 1 # Ein Level höher: Änderungen in "staging" Branch übernehmen und auf Staging-Deployment veröffentlichen $ git checkout staging $ git merge testing $ git push # Prüfen der Änderungen $ curl http://web124.test.frbit.de/changeset This is changeset 1 # Höchstes level: in "live" Branch übernehmen und auf Production-Deployment veröffentlichen $ git checkout live $ git merge staging $ git push # Prüfen der Änderungen $ curl http://web123.test.frbit.de/changeset This is changeset 1
Alle Ausschlüsse und Benutzer müssen in beiden Webprojekten im MISH Control Panel eingetragen werden.