Best Practices für Sandbox-Websites?

Question

Ich arbeite derzeit in einem Webshop mit fast keinen formalen Prozessen und einer Million PHP-Websites, einschließlich knifflige Sachen wie benutzerdefinierte CMS und Warenkorb-Code.

Wir versuchen, Dinge zu verbessern. Ich dränge auf CVS/SVN.

Meine Frage ist, was ist die beste Vorgehensweise für Sandboxing Website Arbeit? Wir sind auf dem LAMP Stack. Einige unserer Websites haben fest codierte (oder von Benutzern eingegebene) Links zur aktuellen Domain. Wenn Sie also eine andere Domain wie zum Beispiel preview.mysite.com einrichten, werden Links, die auf www.mysite.com verweisen, nicht mehr angezeigt. Wenn wir anfangen, Regressionstests anzuwenden, sollten die Domänen vielleicht zum Testen einheitlich sein? Dies kann immer mit einem lokalen Host-Eintrag geschehen.

Also, wenn wir viele Websites haben, wäre es schön, einen Prozess für immer Vorschau in einer richtigen Sandbox zu haben. Ich frage mich, wie dies in einen SVN/CVS-Zyklus integriert werden könnte.

Ich bin nur auf der Suche nach Best Practices der Branche, weil wir versuchen, dorthin zu gelangen. Wenn das bedeutet, eine Site auf einen zusätzlichen Server zu klonen, sei es so.

Answer 1

Also ja, Sie sollten einen zweiten STAGE-Server haben. Was ich tue, ist, meinen Code in CVS auf meine Dev-Box zu legen und regelmäßig zu committen, während ich weitermache. Als ich bin bereit, eine Version auf die „Bühne“ Server zu schieben, gehe ich durch die Dateien, die ich möchte, dass sie Stufe Stufe und Tag:

cvs tag -F STAGE

Dann gehe ich auf die Bühne Server und tut ein Update mit der STAGE Flagge die Bühnenversion von Dateien zu erhalten:

cvs up -r STAGE

Dies auch den sticky-Tag setzt „STAGE“ auf diesen Dateien sein, also in der Zukunft, ich kann Lassen Sie das STAGE-Tag nur bei Aktualisierungen auf meinem Stage-Server:

cvs up

schließlich, wenn ich meinen Code auf der Bühne Server getestet haben, Ich rolle es auf dem Produktionsserver rsync ...

Wir haben mehrere Entwickler arbeiten zusammen, um eine stabile STAGE Version up halten kann schwierig werden. In diesem Fall, wenn ich nur kleine Änderungen an ein oder zwei Dateien habe, werde ich sie einfach einzeln auf den Produktionsserver scp ..

Schließlich, um sicherzustellen, weiß ich, was auf meinen Produktionsservern ist, nachdem ich sende eine Datei oder Dateien auf dem Produktionsserver, taggen alle Dateien auf meinem Bühnenserver als RELEASE, und auch als RELEASE20090713 oder was auch immer das aktuelle Datum ist. Auf diese Weise habe ich bewegende Schnappschüsse durch die Zeit, die ich bei Bedarf bekommen kann. obwohl Hinweis, bedeutet dies nicht den Sticky-Tag aktualisieren, so dass mein regelmäßigen alte

cvs up

auf der Bühne Server wird mir noch die neuesten STAGE-Dateien.

Jetzt in Ihrem Fall, soweit die hartcodierte URLs geht ... Sie wissen schon .. schlecht schlecht schlecht ... so beheben Sie sie, wie Sie gehen ... Aber Sie können möglicherweise Apache URL Neuschreiben verwenden URLs in STAGE umschreiben, um mit einem benutzerdefinierten TCP-Port zu sprechen.

Wenn Sie ein intelligentes Netzwerkgerät wie Cisco Router haben, können Sie es für PAT (Port Address Translation) für Ihre IPs einrichten. Port 80 kann zu Ihrem normalen Produktions-Webserver weiterleiten, und Port 8080 kann zu Ihrem STAGE-Server (dessen Port 80) weiterleiten.Alles, was Sie tun, ist Apache URL Umschreiben auf Ihrem STAGE-Server und Anhängen 8080 an alle Hostnamen, die es sieht. Jetzt werden alle Ihre Posts und Links auf die richtigen STAGE-Server übertragen, und Ihre Apache-Konfigurationen können genauso sein.

Answer 2

In Bezug auf die hart codierten (oder von Benutzern eingegebenen) Domänennamen: Sie könnten die Domänen zu Ihrem hosts file hinzufügen. Das sollte Ihre Probleme während der Entwicklung und Vorschau lösen. Ihr Browser wird die IP-Adresse für www.mysite.com abrufen und 127.0.0.1 oder die IP-Adresse der Vorschau-Site in der Host-Datei finden. Der schwierige Teil besteht darin, dass Sie nicht nur anhand der URL im Browser feststellen können, ob Sie sich auf der Produktionsseite befinden oder nicht. (Die ShowIP addon für Firefox kann Ihnen hier helfen.)

In Bezug auf CVS/SVN: Ich würde wirklich Ratschläge Sie für SVN gehen. Es ist nicht schwieriger zu verwenden als CSV, hat aber einige Vorteile (z. B. Umbenennen ist möglich). Für weitere Informationen siehe z. this question.

Wie für die Vorschau in einer Sandbox, das ist was wir tun: Wir machen die meisten unserer Entwicklung auf trunk (oder auf einem Zweig, aber der Rest des Prozesses ist fast der gleiche). Sobald wir bereit sind, es dem Kunden zu zeigen, erstellen wir eine tag. Mit diesem Tag wird der Vorschau-Server aktualisiert. Wenn der Kunde nicht zufrieden ist, entwickeln wir etwas mehr auf Stamm (oder der Filiale), erstellen ein neues Tag, aktualisieren die Vorschau mit dem Tag, etc. Sobald der Kunde zufrieden ist, verwenden wir das exakt gleiche Tag, das in der Vorschau läuft der Produktionsserver. Auf diese Weise können wir sicher sein, dass der Vorschau- und Produktionsserver dieselbe Codebasis hat.