Git Post-Receive-Hook mit einem Teil des Arbeitsbaums

Ich möchte Git verwenden, um eine Website auf einem Testserver bereitzustellen. Meine Website ist ein WordPress-Theme, das mit Gulp erstellt wurde, und das Repository sieht so aus

theme.git/
-- gulpfile.js
-- src/
-- build/

Ich habe die erklärten Schritte befolgt hier und hier die ein leeres Repository auf dem Server einrichten, den Speicherort des Git-Arbeitsbaums konfigurieren und einen Post-Receive-Hook schreiben, um das Repository an diesen Speicherort auszuchecken.

Das Problem ist, dass ich nur nach Verschieben oder Kopieren suche build/ Ordner an seinen Speicherort auf dem Server. Mein einziger Gedanke war, einen Post-Receive-Hook zu schreiben, der das Repo an einen Ort im Arbeitsbaum zieht (weil ich glaube, gelesen zu haben, dass nackte Repos normalerweise überhaupt keinen Arbeitsbaum haben), und dann cpist der Build-Ordner in wp-content/themes/

Es scheint unnötig kompliziert zu sein, also frage ich mich, ob es einen effizienteren / häufigeren Weg gibt, dies zu tun. Vielen Dank!

Ihr Ansatz zur Nutzung git so umfangreich für das Deployment erscheint etwas seltsam, vor allem, weil Git in erster Linie ein Quellcode-Verwaltungssystem ist, kein Deployment-Tool. Es ist wahr, dass man mit Git-Hooks viele seltsame Sachen machen kann, aber aus irgendeinem Grund spüre ich, dass diese dazu neigen, dich wieder zu verfolgen.

Normalerweise würde ich Ihnen empfehlen, etwas zu verwenden kontinuierliche Integration Werkzeug für den Job. Ein möglicher Workflow, den ich selbst nutzen könnte, wäre

1. Speichern Sie Ihre Designdateien in einem öffentlichen Repository unter GitHub. Es ist kostenlos, es gibt wahrscheinlich keine großen Geheimnisse in Ihrem Theme-Quellcode, und als zusätzlichen Bonus könnten Sie sogar Ihr Theme als Open Source nutzen.
2. Richten Sie einen CI-Job mit ein Travis C.I für Ihr Depot. Sie erhalten im Grunde eine kostenlose Build-Maschineninstanz in der Cloud und können vor oder nach dem Build alle möglichen Dinge tun. Du könntest zB. Lauf gulp build (oder wie auch immer Ihr Aufgabenname lautet) dort, sodass Sie die nicht speichern müssen build Verzeichnis im Git-Repo überhaupt.
3. Im Travis after_success Hook könnten Sie dann das Build-Verzeichnis beispielsweise mit auf den Zielserver kopieren scp. Hier ist ein Beispiel für dasselbe mit FTP. Travis unterstützt Verschlüsselung sensibler Datensodass Sie sich nicht (zumindest so sehr) um das Speichern von Benutzername und Passwort im Git-Repo kümmern müssen.

Dieser Ablauf ist nützlich, wenn Sie den Build jedes Mal bereitstellen möchten, wenn Sie etwas an das Git-Repository übertragen. Übrigens, wenn Sie es zum ersten Mal benutzen, fühlt es sich wirklich wie Magie an: „Das habe ich gerade gemacht git pushund jetzt ist die Änderung bereits live auf meinem Server.”

Sie haben jedoch erwähnt, dass Sie den Code für a bereitstellen möchten Testserver. Es stimmt, dass CI-Tools (wie Travis) verwendet werden können, um einen Fluss zwischen verschiedenen Bereitstellungsschritten aufrechtzuerhalten, von denen viele Testserver sind. Ein Beispielfluss für große Projekte könnte sein

development -> tests passing? -> release -> tests passing? -> integration -> tests passing? -> staging -> tests passing? -> production

…wo der Ablauf teilweise oder vollständig mit einem CI-Tool automatisiert werden könnte.

Sie haben es jedoch so klingen lassen, dass das Bereitstellen von Builds in Ihrem Fall eine einmalige Sache ist, die Sie manchmal nur manuell tun möchten. (Ich entschuldige mich, wenn ich Sie falsch interpretiert habe.) Für diese Art von einmaligen Aufgaben ist die Verwendung von Shell-Skripten oder Aufgabenverwaltungstools geeigneter.

Sie haben erwähnt, dass Sie bereits verwenden gulp. Das ist ein sehr praktisches Werkzeug für den Job, vor allem, weil Sie verschiedene “Aufgabenströme” einfach kombinieren können. Sie könnten eine Aufgabe zum Erstellen des Themas haben (gulp build) und eine weitere für die Testserverbereitstellung (gulp deploy-test), was nur die erweitert build Aufgabe mit einem zusätzlichen Schritt zum Kopieren von Dateien auf den Testserver. Schluck-scp sieht nach einem guten Plugin für die Aufgabe aus (ich habe es jedoch nicht selbst verwendet, es war nur das erste Suchergebnis von Google). Wenn das nicht klappt, können Sie immer anrufen scp manuell mit Schluck-Schale oder ähnliches.

Sie könnten die Bereitstellungsaufgaben sogar so parametrisieren, dass Sie Folgendes tun könnten:
gulp deploy --test und
gulp deploy --production

Bitte schön, das war deine erste Lektion Entwickler. Es gibt eine ganze Welt von Dingen zu lernen, wenn diese Art der Aufgabenautomatisierung in Softwareprojekten für Sie interessant klingt.

Das ist einfach git read-tree Arbeit. Behalten Sie ein Manifest, auch bekannt als Index, für das, was sich in Ihrem Bereitstellungsverzeichnis befindet, und behandeln Sie Ihre Updates mit einem Pre-Receive wie folgt:

#!/bin/sh
while read old new ref; do [[ $ref = refs/heads/master ]] && {
    export GIT_INDEX_FILE=deployment-manifest
    export GIT_WORK_TREE=/path/to/deployment
    git read-tree -um `git write-tree` $new:build || exit 1
}; done

Notiz dass, wenn eine Datei, die auf diese Weise bereitgestellt wird, im Bereitstellungsbaum geändert wurde, die git read-tree hier und der Push schlägt fehl, da Git keinen Inhalt überschreibt, von dem Sie ihm nichts gesagt haben.

Ich benutze git die ganze Zeit für die Bereitstellung. Daran ist überhaupt nichts Verrücktes, und ich weiß nicht, was @cido dagegen hat. Es ist sehr wertvoll, zu jedem Punkt in Ihrem „Deploy“-Zweig in der Zeit zurückgehen und genau sehen zu können, was zu diesem Zeitpunkt auf Ihrem Server live war.

Verwechseln Sie nicht das Git-Repository, das Sie für die Speicherung verwenden, mit dem, das Sie für die Bereitstellung verwenden. Sie sollten einen vollständig sauberen Git-Baum in Ihrem Produktionsbereich (was auch immer das ist) ausgecheckt haben, und wie ich vorgeschlagen habe, möchten Sie vielleicht einen separaten Zweig namens “Bereitstellen” oder “Produktion” oder “Staging” oder was auch immer haben.

Ihr Post-Receive-Hook muss dann nur noch ein Skript ausführen, das in Ihren Produktionsbereich geht und Ihren Deploy-Zweig zum Aktualisieren zieht.

Wenn Sie dies benötigen, um robust zu sein gegen Dateien, die dort außerhalb von Git platziert werden (z. B. temporäre Dateien, die zur Laufzeit generiert werden), dann möchten Sie vielleicht anrufen git clean -dfx vor dem ziehen. Und es gibt noch andere Dinge, die Sie vielleicht tun möchten, wenn Sie davon ausgehen, dass dieser Server regelmäßig von Grund auf neu erstellt wird (z. B. in einer Cloud-Bereitstellung), aber es klingt so, als ob die manuelle Ersteinrichtung für Ihren Anwendungsfall in Ordnung sein sollte .

cpDas Erstellen des Build-Verzeichnisses klingt gut, nur würde ich rsync verwenden, da es im Allgemeinen schneller ist, wenn die Änderungen nur inkrementell sind.

Ich würde Ihr Projekt in zwei Repos aufteilen.

1. Quelle. Inklusive Quelle und was auch immer. Schließt das Verzeichnis /build/ aus. Verwenden Sie dies nur für die Quellcodeverwaltung. Dies geht nie an die Website (es kann unsicher sein, Ihren Code auf der Website zu speichern, selbst in Form eines Git-Repos).

2. Einsatz. Nur /build/ Verzeichnis. Sie können ein neues Git-Repo innerhalb des Verzeichnisses initiieren. Dies hat ein Remote-Repository auf dem Server; Sie können wie zuvor den Post-Receive-Hook zum Bereitstellen verwenden.