Staging- und Liveseite mit Git

[chris085]

Hallo,

ich setze mich aktuell mit einem Konzept auseinander dass eine saubere Lösung Staging- und Liveseite Architektur via Git für eine Webseite haben soll.
Leider habe ich wenig Erfahrung mit dieser Thematik, da ich git nur für Scripte entwickeln benutze und anschließend eben debian Pakete baue.
Wie setzt man so eine Entwicklungs- Produktivumgebung am besten ein.
Wer hat Erfahrungen ?

Danke
Gruß

 

[elias5000]

In unserer Firma benutzen wir git für das Fahren von Development, Preview und Live.

Der master enthält dabei per Definition immer eine releasebare Version. Preview ist ein Branch, der vom master gebrancht wurde.
Wird ein neues Feature implementiert, erfolgt dies in einem Feature-Branch, welcher nach fertiger Implementierung in den Preview gemerged wird. Das Preview-Tag wird dann auf HEAD gesetzt und auf den Preview-Server publiziert.
Nach der Abnahme wird das Feature in den master gemerged. Vor dem Publish wird das letzte Release getaggt (für evtl. nötiges Rollback) und das Live-Release-Tag auf den HEAD gesetzt. Das Live-Release-Tag wird dann auf den Live-Server publiziert.

Der Publish-Prozess ist dann ein (bei uns recht featurereiches) Script, welches einen Publish-Checkout auf den Release-Tag updated und per rsync die Live-Installation updatet und ggf. noch einige Aktionen ausführt (Caches leeren, crontab updaten u.s.w.)

Alternatiov könnte die Live-Installation auch nur ein Clone sein, den man per git auf den aktuellen Release-Tag updatet. Dann spart man sich das Publish-Script.

Für die Zusammenarbeit bei der Entwicklung und als zentralen Sammelpunkt haben wir einen gitosis-Server. Wobei die Feature-Branches nicht auf den gitosis-Server gepusht werden sondern erst der Merge in den Preview-Branch bzw. master submitten das Feature auf den gitosis-Server.

Gelegentlich werden durch Mergen des master in den Preview-Branch Fixes, die direkt im master eingebaut wurden, in den Preview nachgezogen. Und hin und wieder (so einmal im Jahr) kann es nötig sein, den Preview-Branch neu aus dem master zu erzeugen - hauptsächlich, um die Anzeige in gitk nicht zu unübersichtlich werden zu lassen.

Dass der Preview parallel zum master geführt wird ermöglicht es, auf dem Preview schon mehrere Features gleichzeitig zur Abnahme einzubauen und trotzdem die Reinhenfolge der Merges in den master flexibel zu halten.

 

[daemotron]

Für meine Website (Django-basierter Eigenbau) habe ich eine Lösung mit Mercurial gebastelt. Wie bei elias5000 gilt, dass in default/tip nur lauffähiger Code committed werden darf (dazu hat man schließlich eine lokale Entwicklungsumgebung, um das zu testen). Auf dem Staging-"Server" (eigentlich nur ein FreeBSD-Jail) sorgt ein Cron-Job dafür, dass neue Commits innerhalb weniger Minuten auch deployed werden. Das Skript dafür ist recht Django-spezifisch, da insbesondere Updates am Datenmodell ziemlichen Aufwand nach sich ziehen (das kann RoR definitiv besser ).

Für die Produktivumgebung bin ich konservativ - da im Repository nur Code, Templates u. ä., aber keine Inhalte herumlungern, deploye ich im Produktivsystem nur manuell - ein zu deployender Stand wird vorher entsprechend getagged. So häufig kommt das nicht vor; Kleinst-Änderungen (zus. Grafik o. ä.) "merge" ich teilweise sogar von Hand (ich weiß, das ist nicht sauber, geht oft aber schneller).

 

[chris085]

Hi,

bin so weit jetzt einige Steps voran gekommen.
Nun hänge ich an dem Schritt eine Branch auf ein Webverzeichnis zu kopieren/publizieren. Laut Doku soll post-receive hook eigentlich dass richtige sein.
Komme damit leider nicht damit zu recht. Schließlich will ich dass auf Serverebene einrichten und nicht auf Client Basis.
Für Beispiele wäre ich dankbar.

Gruß

 

[Roger Wilco]

Komme damit leider nicht damit zu recht.

Inwiefern?

Schließlich will ich dass auf Serverebene einrichten und nicht auf Client Basis.

Dann mach das doch einfach. Nochmal zur Erinnerung: Git ist ein verteiltes Versionskontrollsystem, d. h. es gibt per Definition keinen zentralen Server, sondern lediglich ein "blessed repository" sofern man sich für solch einen Workflow entscheidet.

Weiterhin bedeutet das, dass Hooks nicht mit übertragen, sondern pro Repository eingerichtet werden müssen, wie und wo steht in githooks(5).

 

[chris085]

Ich habe im Moment ein Repository dass wiederum enthält eine branch testing und eine branch live. Testing soll laut meinem Plan auf test.domain.tld dupliziert werden und live unter domain.tld.

Wenn ich nun mein Repository angucke gibt es die Struktur .git/hooks. Dort sind einige Beispielscripte enthalten.
Mir ist nicht ganz klar, wie sich Änderungen in .git commiten und pushen lassen.
Welchen Inhalt müsste post-receive hook haben ?

Danke

Gruß

 

[Roger Wilco]

Mir ist nicht ganz klar, wie sich Änderungen in .git commiten und pushen lassen.
Welchen Inhalt müsste post-receive hook haben ?

Der post-receive Hook in deinem blessed repository muss einfach die Kommandos enthalten, die du ausführen lassen möchtest, z. B. ein Update (sprich `git pull […]`) des Repositories in deinem DocumentRoot o. ä.

 

[chris085]

Sry dass ich nochmals nachfrage, aber wie bekomme ich mein editierten Hook auf den git server ? Schließlich wird .git nicht berücksichtigt.

 

[Roger Wilco]

Sry dass ich nochmals nachfrage, aber wie bekomme ich mein editierten Hook auf den git server ?

Wie schon mehrfach geschrieben, indem du ihn in deinem "zentralen" Repository anlegst. Wenn es ein bare repository ist, direkt im Verzeichnis "hooks", ansonsten in ".git/hooks".