Git: Anwendungskonfiguration und verschiedene Umgebungen

Question

Wir verwenden git für die meisten Webanwendungen, die wir in unserem Shop erstellen, und obwohl die Anwendungen selbst eine Vielzahl von Technologien (PHP, Rails usw.) verwenden, haben wir im Allgemeinen eine Bereitstellung und Produktion Server für jede Site. In der Regel verfügen diese Server über verschiedene Gruppen von Datenbankanmeldeinformationen sowie verschiedene umgebungsbasierte Konfigurationseinstellungen (z. B. Caching). In unserem Workflow werden in der Regel zwei Git-Zweige pro Projekt verwaltet: Master, der den Produktionsserver widerspiegelt, und Staging, der das Staging widerspiegelt. Neue Funktionen werden für die Bereitstellung (oder einen Unterzweig) entwickelt und nach Abschluss und Bereitstellung wieder mit dem Master zusammengeführt.

Meine Frage bezieht sich auf die beste Möglichkeit, die Konfigurationsdateien zu verwalten, die branchen- und umgebungsspezifisch sind. Ich habe die Antworten von ähnlichen Fragen here und here gesehen, und beide nicht wirklich erfüllt. Die beiden Hauptansätze scheinen zu sein: a) Verwenden von .gitignore-Ausschluss, um Konfigurationsdateien außerhalb der git-Sicht zu belassen, oder b) Schreiben von reflektierendem, umweltbewusstem Code, der z. Welche Datenbankanmeldeinformationen müssen basierend auf dem Hostnamen verwendet werden? Mein Problem mit a) ist, dass es nur einen Satz von Konfigurationsdateien in der Codebasis gibt (unabhängig vom aktuellen Zweig), so dass die Konfigurationsdateien der anderen Umgebung verloren gehen. b) andererseits scheint nur unnötige Modifikation der Codebasis in einer Weise zu erfordern, die sich nicht auf die Funktionalität der Anwendung bezieht.

Idealerweise hätte ich gerne einen Weg, um Konfigurationsdateien innerhalb eines bestimmten Zweiges zu "sperren", so dass ich immer die Master-Konfigurationsdateien erhalte, und wenn ich das Staging auschecke, bekomme ich die Staging-Konfigurationsdateien. Außerdem sollte das Zusammenführen von Staging in Master die Master-Konfigurationsdateien in keiner Weise beeinflussen. Bisher haben wir uns damit beschäftigt, Ordner mit umgebungsspezifischen Konfigurationsdateien außerhalb des git-Stammverzeichnisses zu haben und die entsprechenden Dateien bei der Bereitstellung manuell in die Codebasis zu verschieben, aber das ist natürlich unnötig hackig (und möglicherweise gefährlich).

Gibt es eine Möglichkeit, dies mit Git zu erreichen?

Vielen Dank für Ihre Aufmerksamkeit!

Answer 1

Nicht sicher, warum Leute denken, dass sie ohne eine Art Installationstool davonkommen können. Bei Git geht es um die Verfolgung der Quelle, nicht um die Bereitstellung. Sie sollten immer noch ein "make install" -Typ-Tool haben, um von Ihrem Git Repo zu der eigentlichen Bereitstellung zu gelangen, und dieses Tool kann verschiedene Dinge tun, wie zum Beispiel die Vorlagenerweiterung oder die Auswahl alternativer Dateien.

Zum Beispiel haben Sie möglicherweise "config.staging" und "config.production" in git eingecheckt, und wenn Sie im Staging bereitstellen, wählt das Installationstool "config.staging" aus, um es nach "config" zu kopieren. Oder Sie haben eine einzelne "config.template" -Datei, die als Vorlage dient, um "config" in der Bereitstellung zu machen.

Answer 2

Ich nehme an, dass master nur Commits hält, die bereits in staging sind. Wenn Sie einen zusätzlichen Commit zu master hinzufügen, der die Unterschiede in der Konfiguration zwischen den beiden Zweigen enthält, sollte die erneute Konfiguration dieses Commits über das, was von staging gezogen wird, die Konfiguration beibehalten. Dies ist nicht ganz so einfach wie "das Zusammenführen von Staging in Master sollte Master-Konfigurationsdateien in keiner Weise beeinflussen", aber da Sie in diesen Fällen einen Zusammenführungskonflikt bekommen, ist es möglicherweise nahe genug.

Answer 3

Sie können versuchen, die Post-Merge oder Post-Checkout-Hooks zu verwenden, um zu überprüfen, ob alles so ist, wie es sein sollte, und es andernfalls zu beheben. Dies ist eigentlich seems to be suggested by the ProGit book.

Das Konzept besteht darin, diese Hooks als "make install" -Skripts zu schreiben, die die korrekte Konfiguration nach Zweig, Host, Vorhandensein oder Inhalt anderer Dateien nach Belieben sicherstellen.Die Hooks könnten sogar Ihre Konfigurationsdateien neu schreiben oder sie durch Ausfüllen von Vorlagen neu erstellen.