Beibehalten der Konfigurationsunterschiede zwischen Entwicklungs- und Live-Umgebungen während der Bereitstellung von SVN

Question

Wir verwenden das ExpressionEngine CMS (php) zum Erstellen von Websites. Für jede Site richten wir ein Subversion-Repository ein und binden die EE-Installation sowie alle verwendeten benutzerdefinierten Vorlagen, Bilder, Javascript usw. ein. Im Repository ist die Datei enthalten, die alle Umgebungsvariablen und die .htaccess-Datei enthält.

Wir haben einen Entwicklungsserver mit einer Arbeitskopie des Repositorys, die über Post-Commit aktualisiert wird, die wir verwenden, um zu entwickeln. Wenn wir bereit sind zu veröffentlichen, erstellen wir einen Zweig in Subversion, nehmen alle für die Produktionsumgebung erforderlichen Änderungen vor, markieren die Versionsnummer, exportieren das Repository, laden es in ein neues Verzeichnis auf dem Live-Server hoch und symbolisieren die Dateien an Ort und Stelle. Ein Rollback ist so einfach wie eine Symlink-Verknüpfung zur vorherigen Version.

Das Problem ist dieser Schritt, in dem wir die Umgebungsvariablen ändern müssen, die für die Entwicklungs- und Produktionsserver unterschiedlich sein müssen. Das sind Dinge wie das (Kommentieren) von Htaccess - Regeln, die zu den falschen Stellen umleiten, Google Map API - Schlüssel austauschen, weil die Domains unterschiedlich sind, Skripte ausführen, die das Javascript in eine verschleierte Datei minimieren, um die Größe und HTTP - Verbindungen zu halten usw .

Die Frage ist, wie könnte das mehr automatisiert werden? Wir würden uns freuen, das Freigabeverfahren auf das Nötigste zu reduzieren. Ich bin vertraut mit der Existenz von Werkzeugen wie Capistrano und Make, aber ich bin nicht sicher, wie ich sie dazu bringen könnte, alle notwendigen Dateien zu modifizieren ... wie würdest du so etwas organisieren? Ist es das wert, Zeit zu investieren, wenn es vielleicht einmal alle paar Wochen passiert?

Answer 1

Viele der Konfigurationsoptionen könnten durch Einschalten von $ _SERVER ['HTTP_HOST'] behoben werden.

Zum Beispiel

switch ($_SERVER['HTTP_HOST']) { 
    case 'developement.domain.com': 
     $api_key = "dev environment api key"; 
     break; 
    default: 
     $api_key = "live environment api key"; 
} 

Dann für .htaccess Fragen Sie eine alternative .htaccess-Datei in Ihrer vhost Definition mit der Anweisung Access einstellen:

<VirtualHost *:80> 
    ServerName sitename 
    AccessFileName .htaccess-dev 
</VirtualHost> 

Answer 2

Ich gehe mit diesem Problem durch Hinzufügen von Konfigurationsdatei zu Subversion ignorieren Liste. Es wurde bereits angesprochen hier auf Stackoverflow: see question #149485

Grundsätzlich halte ich nur setup.default.php in SVN, und in jeder Installation kopiere ich es manuell setup.php, die auf Ignore-Liste ist. Dies verhindert, dass die Datei erneut in den Repo eingecheckt wird. Es gibt selten Änderungen an dieser Datei und sie können behandelt werden, wenn die Anforderung auftritt.

Answer 3

Eine weitere Alternative ist die Konfigurationsdateien verzweigen Klicken Sie einmal in einen Versionszweig und markieren Sie sie dann als bearbeitet am Ziel, und verwenden Sie dann ein Zusammenführungsskript, das sich daran erinnert, wie eine dreifache Zusammenführung durchgeführt wird. Wenn sich die Konfiguration in der Quelle ändert, wird wahrscheinlich ein Konflikt generiert, was eine gute Sache ist, da Sie wahrscheinlich ähnliche Änderungen am Ziel vornehmen müssen.

So behalten Sie zwei Bäume für die Lebensdauer des Projekts: Entwicklung und Freigabe. Wenn die Dinge in der Entwicklung reifen, integrieren Sie sie zur Veröffentlichung. Sie können auch eine dritte, QA-Struktur haben, wenn Sie einen komplizierteren Release-Prozess haben.

Wenn Sie eine neue Version erstellen, kopieren Sie aus dem Arbeitsbereich in den Bereich "Release" (als Zusammenführung/Integration), anstatt eine brandneue Verzweigung zu ziehen. Wenn Sie zu diesem Zeitpunkt auch eine Momentaufnahme des Releasebaums wünschen, erstellen Sie einen separaten Zweig/Kopie/Tag, den Sie nur für Archivierungszwecke verwenden.

Btw: Dies ist einer der Bereiche, in denen Perforce glänzt - es erinnert sich, was Sie bereits zusammengeführt haben, und wird nie versuchen, zweimal zusammenzuführen.

Answer 4

Wir kümmern uns darum, indem wir ein konfigurationsspezifisches Verzeichnis führen.

So zum Beispiel, wenn Sie unterschiedliche .htaccess und config.php Dateien zwischen Entwicklern und Produktion sie in/trunk/config/{Umgebung} beibehalten würde/

Wir verwenden ant/Nant Skripte Release erstellen Pakete, und die Skripte haben eine Build-Aufgabe für jede Umgebung. Diese Aufgaben übernehmen die Konfigurationsdateien.

-

Ein weiterer Kommentator schlägt HTTP_POST einschalten. Leider kann ich nicht direkt kommentieren (nicht genug Rep). Die Verwendung von HTTP_POST zur Ermittlung der Umgebungskonfiguration hat potenzielle Sicherheitsprobleme, da der Wert hierfür vom Client stammt.