Ich würde sogar in Betracht ziehen, Git für die Bereitstellung zu verwenden. Sehr gute Praxis .

Die beiden von Ihnen aufgelisteten Probleme haben sehr wenig mit der Verwendung von git für die Bereitstellung selbst zu tun. Ersetzen Sie die Konfigurationsdatei mit den Datenbankkennwörtern durch .git / , und Sie haben das gleiche Problem. Wenn ich Lesezugriff auf Ihr Webstamm habe, habe ich Lesezugriff auf alles, was darin enthalten ist. Dies ist ein Problem der Serverhärtung, das Sie mit Ihrer Systemadministration besprechen müssen.

git bietet einige sehr attraktive Vorteile in Bezug auf die Sicherheit.

1. Sie können ein System für die Bereitstellung in der Produktion erzwingen. Ich würde sogar einen Post-Receive -Hook konfigurieren, der automatisch für die Produktion bereitgestellt wird, wenn ein Commit für master vorgenommen wird. Ich gehe natürlich von einem Workflow aus, der dem Git-Flow ähnelt.

2. Git macht es extrem einfach, den in der Produktion bereitgestellten Code auf eine frühere Version zurückzusetzen wenn ein Sicherheitsproblem angesprochen wird. Dies kann hilfreich sein, um den Zugriff auf geschäftskritische Sicherheitslücken zu blockieren, für deren Behebung Sie Zeit benötigen.

3. Sie können ein System erzwingen, bei dem Ihre Entwickler die von ihnen vorgenommenen Commits unterschreiben müssen. Dies kann dabei helfen, festzustellen, wer was für die Produktion bereitgestellt hat, wenn eine absichtliche Sicherheitslücke gefunden wird.

ol>

Es ist nichts Falsches daran, von einem Git-Repo aus bereitzustellen. Tatsächlich ist dies eine weit verbreitete Praxis und, wie Sie sagen, viel weniger fehleranfällig als das Kopieren von Dateien über FTP oder Rsync.

Angesichts der von Ihnen bereitgestellten Informationen würde ich die folgenden Punkte beachten:

• Ziehen Sie nicht nur den neuesten Master ein. Die Produktion sollte über ein Release-Tag bereitgestellt werden. Verwenden Sie Git Flow oder ähnliches, um mehr Informationen über die Bereitstellung des Codes und die Erstellung der Tags zu erhalten. Da Tags zu einem bestimmten Zeitpunkt eine unveränderliche Referenz auf Ihren Code sind, ist sie stabiler als der Verweis auf einen Hauptzweig, der durch ein fehlerhaftes Festschreiben aktualisiert werden könnte.

• Bezüglich der Bereitstellung des. Git-Verzeichnis Dies sollte kein großes Problem sein. Leiten Sie einfach alles, was mit .git vorangestellt ist, auf 404 in .htaccess um.

• Ihre Git-Authentifizierung sollte auf SSH-Schlüsseln basieren, damit keine Repo-Passwörter auf dem Server gespeichert werden müssen.

Hurra für Git-Bereitstellungs-Workflows!

Ich werde hier der Meinung der Bevölkerung nicht zustimmen. Git dient der Versionskontrolle, nicht der Bereitstellung / CI.

Die hier empfohlenen Methoden eignen sich gut für kleine Projekte, lassen sich jedoch im Allgemeinen nicht sehr gut skalieren.

... was nicht heißt, dass Sie nicht weiter machen sollten, was Sie tun. Denken Sie im Verlauf Ihrer Karriere daran, dass die Projekte, an denen Sie arbeiten, wahrscheinlich aus einem rein git-basierten Bereitstellungsworkflow herauswachsen.

Der wichtigste Paradigmenwechsel besteht darin, nicht mehr über die Bereitstellung von Zweigen nachzudenken Denken Sie über das Bereitstellen von Build-Ergebnissen nach und fügen Sie Umgebungsabhängigkeiten ein, um Ihre Infrastruktur von Ihrer Verzweigungsstrategie zu entkoppeln.

Verwenden Sie beispielsweise das obige Paradigma zum Bereitstellen von Dateien und zum Rollback. Wenn Sie Dateien bereitstellen, können Sie mehrere Versionen der Anwendung auf dem Produktionsserver behalten. Wenn Sie ein Rollback durchführen müssen, können Sie Ihren Webserver auf eine ältere Version verweisen, indem Sie das Webstammverzeichnis erneut verknüpfen. Zwei Shell-Befehle, Mikrosekunden Ausfallzeit, weniger Fehleranfälligkeit als bei Verwendung von git.

Ein weiteres Beispiel: Sie haben den Standard-Dev-Zweig> Staging-Zweig> Master-Workflow mit jeweils einem Server. Sie haben Dinge bereit für die Entwicklung, aber einige andere Dinge zur Bereitstellung haben die Qualitätssicherung fehlgeschlagen. Sie müssen also einige hässliche Vorgänge ausführen - die fehlerhaften Commits von der Bühne entfernen, die Phase erneut bereitstellen sowie die fehlerhaften Commits in der Entwicklung entfernen oder beheben und hoffen, dass Entwicklung und Staging nicht nicht synchron sind.

Was ist stattdessen, wenn Sie einen Release-Zweig vom Master abschneiden, das Material, das für diesen Release-Zweig bereit ist, zusammenführen und das Ergebnis erstellen, einen Testserver in AWS hochfahren und das Ergebnis dort bereitstellen, Ihre Qualitätssicherung ausführen und funktionsfähig sind Tests gegen diesen temporären Staging-Server und dann das gleiche Ergebnis in den Produktionscluster übertragen und bereitgestellt? Nehmen Sie dann die temporäre Staging-Box außer Betrieb, die Sie hochgefahren haben, führen Sie die Freigabe in Master zusammen und kennzeichnen Sie Master mit einer Versionsnummer.

Das sind natürlich extreme Beispiele. Normalerweise ist es nicht so sauber, selbst wenn wir es wollen - Sie müssen wahrscheinlich einige Build-Prozesse in der Zielumgebung ausführen, da Datenbankänderungen erforderlich sind. Und wenn Sie zwischen den Versionen nicht-idempotente Datenbankmods haben, wird das Rollback nicht so einfach sein, egal welche Methode Sie verwenden, da Sie die Datenbank zurücksetzen müssen (im Allgemeinen versuchen Sie, die idempotente Datenbank bereitzustellen Änderungen, und entfernen Sie dann die veralteten Datenbankbits in einer späteren Version, nachdem Sie sicher sind, dass sie nicht mehr im Anwendungsfluss sind.

Wie auch immer, ich denke, was ich vorhabe, ist meine Antwort auf "Ist die Verwendung von Git für die Bereitstellung eine schlechte Praxis?" ist im Allgemeinen "Ja", genauso wie die Verwendung von Stützrädern für das Fahrradfahren schlecht ist. Es ist eine Verbesserung, wenn Sie Ihren Arsch wiederholt auf dem Beton platzen lassen, aber Sie wachsen hoffentlich irgendwann heraus.

Sie können das Argument --separate-git-dir = <git dir> verwenden, wenn Sie den git-Klon aufrufen. Dadurch wird ein symbolischer Link in das Verzeichnis .git eingefügt (symbolisch für Git, ich glaube nicht, dass es sich um einen symbolischen Link zu Ihrem Betriebssystem handelt), und Sie können den <git dir> code angeben > an einen Ort außerhalb des Dokumentstamms.

Ein alternativer Ansatz, den ich zuvor gewählt habe, ähnelt Terry Chias Kommentar zu Hooks nach dem Empfang.

Git verfügt über eine Reihe von Hooks, die für die Ausführung verwendet werden können Alle Arten von Aufgaben vor / während / nach mehreren verschiedenen Aktionen.

Erstellen Sie ein nacktes Repository an einer anderen Stelle als in Ihrem Webordner. Das Bare-Repository kann dann als Remote zum Push verwendet werden, und ein Post-Receive-Hook kann ausgelöst werden, um den neuen Code in ein angegebenes Verzeichnis auszuchecken.

Dieser Ansatz hat Einige Vorteile: Der Bereitstellungsort fungiert als "Einbahnstraße", in der Code die Quellcodeverwaltung durchlaufen muss, um in die Produktion zu gelangen. Sie können verschiedene Zweige / Versionen an verschiedenen Standorten bereitstellen (alle aus demselben Bare-Repo). Es bietet auch eine schöne einfache Möglichkeit zum Rollback mit der Standard-Git-Prüfung. Eine Einschränkung / Konsequenz davon ist jedoch, dass Codeänderungen auf dem Server nicht in Git widergespiegelt werden (nackte Repositorys haben keine Arbeitsverzeichnisse) git --work-tree = / path / to / code status manuell ausführen, um Änderungen zu sehen (aber Sie sollten den Produktionscode trotzdem nicht ändern, oder?)

Ich stimme Terry Chia zu, dass dies eine sehr gute Praxis ist. Es stellt sicher:

• , dass die vorhandene Revision die richtige ist,
• mit allen benötigten Dateien und prüft die Vollständigkeit der Version,
• Machen Sie die Bereitstellungsprozedur schnell und einfach.

Aber ich muss hinzufügen, dass es einige Einschränkungen gibt, die ich gerne teilen möchte.

Normalerweise legen Sie Folgendes in ein Git-Repository:

• Code,
• Dokumente,
• Unit-Tests,
• Bereitstellungsskripte,
• Integrationstools, .deb-Archive,
• SQL-Patches
• oder ähnliches und vielleicht ein paar andere

Nun, in der Produktion wollen Sie nur den Code!

Weil Dokumente, Komponententests, Tools oder .deb-Archive viel Speicherplatz beanspruchen können und in der Produktion nichts zu tun haben

Mit Subversion (vor Version 1.7) können Sie nur das Verzeichnis src / auschecken und haben alle Vorteile. Aber mit Subversion> 1.7 und Git können Sie das nicht tun.

Eine Alternative wäre die Verwendung von Git-Submodulen, um diese Art von Architektur zu erstellen: project repo | - doc | - src -> submodule to project-src repo. \ tests Aber dann würden Ihr Projekt / Ihre Tests und Ihr Projekt-src-Code nicht synchronisiert und das wäre wirklich scheiße.

Die Lösung wäre dann, "sparse checkout" zu verwenden, siehe: https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository

Sie können also git verwenden , aber bitte seien Sie vorsichtig mit diesen Nachteilen.

Hier ist das Skript, mit dem ich Git zum Push-to-Prod mache.

https://gist.github.com/Zamicol/f160d05dd22c9eb25031

Es wird davon ausgegangen, dass alles, was an den Hauptzweig gesendet wird, für die Produktion bereit ist. Alle anderen geschobenen Zweige werden ignoriert. Sie können dieses Hook-Skript an Ihre Bedürfnisse anpassen.

In Bezug auf Ihre Bedenken platziere ich mein Git-Verzeichnis unter / var / git und meine Produktionsdateien an einer anderen Stelle (wie / var / www) und beschränke den Zugriff zu diesen Verzeichnissen.

Sie können Ihr Git-Repo auch auf einem von Ihrem Produktionsserver getrennten Server haben und dann so etwas wie scp und ssh im verwenden Skript oben, um Ihre Dateien vom Git-Server auf den Produktionsserver zu verschieben. Auf diese Weise können Sie weiterhin git verwenden, um zu prod zu pushen, während Sie Ihren Code von Ihrer Produktion trennen.