Momentan verwende ich Mercurial, um ähnliche Apache-Konfigurationen zwischen den Produktions- und Entwicklungsservern zu synchronisieren. Eine zusätzliche Patch-Warteschlange fügt die Änderungen und zusätzlichen Dinge hinzu, die für den Entwicklungsserver erforderlich sind.
Das Schema funktioniert, aber es könnte besser sein. Ich bekomme immer Zusammenführungskonflikte, wenn ich die Patch-Warteschlange erneut anwende, nachdem ich Änderungen aus den Bereitstellungskonfigurationen gezogen habe. Ich habe das Gefühl, dass ich immer identische Änderungen an den separaten http://- und https://-Konfigurationsdateien vornehme.
Wie kann ich die identischen Bits zwischen meinen :80- und :443-Apache-Konfigurationen herausfiltern und die „zusätzlichen Bits“ sauberer zur Entwicklungskonfiguration hinzufügen?
Antwort1
Sie können die Verwendung vonEnthaltenFunktion des Apache-Konfigurationssystems. Trennen Sie dann die Elemente Ihrer Konfiguration, die für eine einzelne Maschine spezifisch sind, in eine_local.confdas sollte das Zusammenführen einfacher machen
Antwort2
Apache bietet die Möglichkeit, bestimmte Konfigurationen selektiv zu aktivieren. So können Sie dieselbe Konfigurationsdatei für Entwicklung und Produktion verwenden. Starten Sie Apache mit -DDEVELOPMENT oder -DPROD und Sie können Tags für die Konfiguration verwenden, die spezifisch für den Entwicklungsserver ist. Auf diese Weise treten keine Zusammenführungskonflikte auf (es sei denn, Sie ändern natürlich beide Entwicklungs-/Produktionskonfigurationsdateien vor der Zusammenführung).
Antwort3
Das mag altmodisch sein, aber meine Apache-Konfigurationen für die Bühne und die Produktion waren identisch, außer dass einige der Parameter darin unterschiedlich waren (z. B. IP-Adresse). Ich habe einen Perl-Wrapper um ein Startskript verwendet, um die Lücken systematisch zu füllen. Die eigentlichen Basiskonfigurationsvorlagen waren tatsächlich identisch.
Dadurch wurde sichergestellt, dass der Stage-Apache funktional mit dem Produktions-Apache identisch war.
Durch die Weitergabe dieser Produktionskonfiguration an die Entwicklungsabteilung konnten diese so produktionsnah testen, wie sie wollten (und das wollten sie, denn sie würden nicht mit der Produktion beginnen, wenn ihre Sachen nicht in der Phase „funktionierten“. Wir haben gelegentlich Hilfe bereitgestellt (beispielsweise für die Mod_Rewrite-Regeln) und den Rest dem Entwickler überlassen.
Der Unterschied zwischen dieser speziellen Konfiguration und anderen Orten, an denen ich gearbeitet habe, ist:
Die Entwicklungsmitarbeiter wurden ermutigt, sich in Bereichen zu versuchen, die nicht direkt mit den Programmen zusammenhingen, an denen sie arbeiteten. Das heißt: Sie arbeiteten möglicherweise an Back-End-Anwendungen (und mussten daher nicht viel über Apache wissen), konfigurierten jedoch ihre eigenen Apache-Server (bauten tatsächlich ihre eigenen Desktops, aber das ist meiner Meinung nach zu weit gegangen).
Tatsächlich war der operative Betrieb für einen Großteil der Infrastruktur zuständig, anstatt sie nur zu betreiben.