Лучшие практики веб-сайта для песочницы?

Question

В настоящее время я работаю в интернет-магазине, где практически нет формальных процессов, и миллион веб-сайтов на PHP, включая такие сложные вещи, как пользовательская CMS и код корзины покупок.

Мы пытаемся что-то улучшить. Я настаиваю на CVS / SVN.

Мой вопрос: какова лучшая практика для работы сайта с песочницей? Мы в стеке ЛАМПЫ. Некоторые из наших сайтов имеют жестко заданные (или введенные пользователем ссылки) на текущий домен, поэтому при настройке другого домена, например preview.mysite.com, будут нарушены ссылки, указывающие на www.mysite.com. Если мы начнем применять регрессионные тесты, возможно, домены должны быть единообразными для тестирования? Это всегда можно сделать с помощью записи локального хоста.

Итак, учитывая, что у нас много сайтов, было бы неплохо иметь один процесс, чтобы всегда делать предварительный просмотр в правильной песочнице. Хотите знать, как это интегрируется с циклом SVN / CVS.

Я просто ищу лучшие отраслевые практики, потому что мы пытаемся туда добраться. Если это означает клонирование сайта на дополнительный сервер, пусть будет так.

Answer 1

Что касается жестко закодированных (или введенных пользователем) доменных имен: вы можете добавить домены в файл hosts . Это должно решить ваши проблемы во время разработки и предварительного просмотра. Ваш браузер получит IP-адрес для www.mysite.com и найдет 127.0.0.1 или IP-адрес сайта предварительного просмотра в файле hosts. Сложность в том, что, просто взглянув на URL в браузере, вы не сможете определить, смотрите ли вы на рабочем сайте или нет. ( ShowIP addon для Firefox может помочь вам здесь.)

Относительно CVS / SVN: я бы действительно посоветовал вам перейти на SVN. Он не сложнее в использовании, чем CSV, но имеет некоторые преимущества (например, возможно переименование). Для получения дополнительной информации, например, см. этот вопрос .

Что касается предварительного просмотра в песочнице, то именно это мы и делаем: большую часть нашей разработки мы выполняем на trunk (или на ветке, но остальная часть процесса почти такая же). Как только мы готовы показать это клиенту, мы создаем тег . Этот тег используется для обновления сервера предварительного просмотра. Если клиент не удовлетворен, мы разрабатываем дополнительную информацию по соединительной линии (или ветви), создаем новый тег, обновляем предварительный просмотр с помощью тега и т. Д. Как только клиент удовлетворен, мы используем точно такой же тег, выполняющийся при предварительном просмотре, чтобы также обновить производственный сервер. Таким образом, мы можем быть уверены, что сервер предварительного просмотра и рабочий сервер имеют одинаковую базу кода.

Answer 2

Так что да, у вас должен быть второй сервер STAGE. Что я делаю, так это помещаю свой код в CVS на моем компьютере разработчика и регулярно выполняю коммиты. Когда я готов отправить версию на сервер «STAGE», я просматриваю файлы, которые хочу поместить в STAGE, и отмечаю их STAGE:

тег cvs -F STAGE

Затем я иду на сервер STAGE и делаю обновление с флагом STAGE, чтобы получить версию файлов STAGE:

cvs up -r ЭТАП

Это также устанавливает для этих файлов липкий тег «STAGE», поэтому в будущем я могу просто оставить тег STAGE отключенным, когда я обновляю свой сервер сцены:

cvs up

наконец, когда я проверил свой код на сервере STAGE, я перекатил его на рабочий сервер с помощью rsync ...

У нас есть несколько разработчиков, работающих вместе, поэтому поддержание стабильной версии STAGE может оказаться непростым делом. В этом случае, если у меня есть небольшие изменения в одном или двух файлах, я просто отправлю их по отдельности на рабочий сервер ..

Наконец, чтобы убедиться, что я знаю, что находится на моих производственных серверах, после того, как я отправляю файл или файлы на рабочий сервер, я отмечаю все файлы на моем рабочем сервере как RELEASE, а также как RELEASE20090713 или любой другой текущий дата ... Таким образом, у меня есть движущиеся снимки, хотя время, которое я могу получить при необходимости. Обратите внимание, что это не обновляет прикрепленный тег, поэтому мой обычный старый

cvs up

на сценическом сервере все еще получает последние файлы STAGE.

Теперь в вашем случае, что касается жестко закодированных URL-адресов ... Вы уже знаете ... плохо плохо плохо ... так что исправляйте их по ходу дела ... Но вы можете использовать переписывание apache URL для перезаписи URL-адреса на STAGE для связи с пользовательским портом TCP.

Если у вас есть интеллектуальное сетевое устройство, такое как маршрутизатор cisco, вы можете настроить его на выполнение PAT (трансляция адресов портов) для ваших IP-адресов. Порт 80 может перенаправлять на ваш обычный производственный веб-сервер, а порт 8080 может пересылать на ваш сервер STAGE (его порт 80). Тогда все, что вам нужно сделать, - это переписать apache do URL на вашем сервере STAGE и добавить 8080 ко всем именам узлов, которые он видит. Теперь все ваши сообщения и ссылки будут отправляться на правильные серверы STAGE, и ваши настройки Apache также могут быть точно такими же.