Richtiges Bereitstellen von Anwendungen von der Entwicklung bis zur Produktion und Umgang mit Konfigurationen mit mehreren Standorten. Alle meine Entwicklungen werden über die Datei var / svn / myapp / trunk durchgeführt, und der tatsächliche Produktionscode befindet sich in / var / www / myapp.

Ich checke den neuesten Code auf meinem lokalen Computer in einem Verzeichnis namens "myapp_latest_svn" aus. Ich habe site- und standortspezifischen Code in meiner main settings.php, der H_PATH = 'hat.http://myapp.comDie & db config-Einstellungen für db_host, db_user_name und db_password unterscheiden sich bekanntermaßen in den lokalen Computereinstellungen (wobei localhost / myapp.com nur ein Apache-Alias ​​ist) und auf dem Produktionsserver (die Live-Site läuft auf myapp.com).

Auch die .htaccess-Datei unterscheidet sich von der auf dem Produktionsserver. Kurz gesagt, es gibt eine Reihe von Unterschieden zwischen Entwicklung und Produktion.

Ich behalte meine ganze Arbeit in SVN. Jeden Morgen verwende ich SVN Update, das den neuesten Code für mein lokales SVN-Repository aktualisiert. Wenn ich bereit bin, live zu gehen, erstelle ich mit svn Commit ein Release.

Dann muss ich in der Veröffentlichung daran denken, alle entsprechenden dev-Dateien auf das Produktions-Gegenstück umzustellen. Jetzt musste ich die Produktionseinstellungen.php und .htaccess manuell bearbeiten, um die ortsspezifischen Änderungen wiederzugeben.

Ich bin auf der Suche nach einem automatisierten Weg von der Entwicklung zur Produktion mit vollständiger Versionierung und ohne manuelle Bearbeitung von Dateien, was fehleranfällig und nachteilig ist.

Eine Möglichkeit besteht darin, die Produktionsversion von Dateien schreibgeschützt zu machen (0444). Auf diese Weise werden SVN-Exporte nicht von der Dev-Version der Dateien überschrieben, und ich muss mich nicht darum kümmern, die Dateien bei jedem Wechsel von Dev zu Production zu bearbeiten. Aber das ist eine schlechte Art, Dinge wie kontinuierliche Integration zu tun.

Erstellen Sie auch mehrere Kopien der settings.php (eine für localhost, beta und prod). Verwenden Sie dann ein Shell-Skript, das aus svn exportiert, und ersetzen Sie nach Abschluss des Exports die settings.php durch die richtige settings.php, je nachdem, an welchem ​​Speicherort wir sie bereitstellen. Auf diese Weise wird alles automatisiert. Das ist aber auch ein schlechter Weg.

Der letzte Weg ist

if( eregi ("myapp.com$", $_SERVER['HTTP_HOST']) ){

    define('H_PATH', 'myapp.com');

} else {

    define('H_PATH', 'localmyapp.com');

}

Dies ist in Bezug auf settings.php in Ordnung. Aber was ist mit .htaccess? Du kannst nicht wie oben in .htaccess nachschauen.

Was ich nicht jedes Mal tun möchte, wenn ich meine Site bereitstelle, muss ich die Einstellungen ändern.

Mein DB-Schema befindet sich nicht in der Versionskontrolle, daher ist db bei mir kein Problem, nur die settings.php und .htaccess.

Wie kann ich svn auch anweisen, einige Verzeichnisse nicht zu aktualisieren, da dies auch standortspezifisch ist (/ log, / cache, / assets, / downloads). Ich muss auch den Apache (www_data) Schreibzugriff für die oben genannten Dateien intakt halten.

Zum Schluss möchte ich nicht das leere Trunk-Verzeichnis und die .svn-Dateien auf den Produktionsserver kopieren, wenn ich exportiere.

Wie kann ich Phing oder sogar ein Shell-Skript zum Integrieren verwenden, ohne eines dieser Probleme zu verursachen, wenn ich von svn auf Produktionsserver aufbaue?

Dies könnte für viele Möchtegern-App-Entwickler von Nutzen sein.

Danke im Voraus,

okptime