Как я могу обновить свой сайт, не заставляя пользователей ждать?

Простои неудобны для пользователей, и в настоящее время им приходится ждать каждый раз, когда обновляется движок сайта. Кроме того, при использовании готовых сценариев существует риск того, что изменение настроек будет работать не так, как предполагалось (даже если они были протестированы на промежуточном сайте).

Как я могу хранить несколько версий сайта на сервере и переключаться между ними, не вызывая простоев (например, с помощью файла htaccess)?

Вы на машине Linux / BSD? Если это так, вы можете легко использовать символические ссылки для достижения этой цели.

Создайте версию 1 сайта здесь:

/var/www/www.example.org.v1

Создайте символическую ссылку, указывающую на этот каталог

cd /var/www
ln -s www.example.com.v1 www.example.com

Это должно дать вам каталог list ( ls -la), который выглядит примерно так:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:35 www.example.com -> www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:35 www.example.com.v1

Настройте свой веб-сервер для использования в /var/www/www.example.comкачестве корневого документа. Вам никогда не придется менять это; все перенаправление будет выполнено на уровне файловой системы.

Теперь, когда вы хотите поменять местами версию 2 сайта, все, что вам нужно сделать, это поместить новую версию в:

/var/www/www.example.org.v2

И обновите символическую ссылку, чтобы указать на эту версию:

ln -sfh www.example.com.v2 www.example.com

Из-за чего вывод вашего каталога будет выглядеть так:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:43 www.example.com -> www.example.com.v2
drwxr-xr-x   2 userid  users   512 Aug  3 03:42 www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:41 www.example.com.v2

Как видите, символическая ссылка www.example.com теперь указывает на версию 2 вашего сайта. Это атомарная операция, которая не должна вызывать простоев, связанных с недоступностью файлов.

Конечно, все еще существует значительная сложность, необходимая для обеспечения обновления структур базы данных, наличия любых статических ресурсов (и привязки к правильной версии) и т. Д., Но по крайней мере для этого необходимо убедиться, что все нужные ресурсы для новый сайт доступен мгновенно.

Windows Vista и Server 2008 также поддерживают символические ссылки с помощью mklinkкоманды, хотя у меня нет прямого опыта работы с ними.

Вы можете использовать виртуальные хосты в Apache, чтобы иметь 2 версии кода на 2 разных URL. Обычно используемый пример:

test.example.com -> /var/www/version1.2

www.example.com -> /var/www/version1.1

оба из которых находятся на одном сервере, но, возможно, только один доступен миру. Как только вы убедитесь, что test.example.com работает, вы можете просто изменить их расположение в конфигурации Apache и ... presto. Новый сайт, новый код. Предполагая, что не было никаких изменений схемы базы данных, это должно работать. Поэтому после внесения изменений это будет:

test.example.com -> / var / www / newtestversion

www.example.com -> /var/www/version1.2

Вот пример директивы конфигурации Apache для виртуального хоста:

<VirtualHost *:80>

     ServerAdmin gabe@localhost

     DocumentRoot "/var/www/version1.1"

     ServerName test.example.com

</VirtualHost>

Для получения дополнительной информации о том, как это сделать, см. Документацию виртуального хоста apache.

Я не уверен, как это сделать в IIS, но я думаю, что есть и способ.

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

В IIS вы можете настроить второй виртуальный каталог с вашими обновлениями.

Затем вы перенаправляете все запросы или переназначаете привязки второго сайта на желаемое имя хоста.

Перенаправление HTTP в IIS 7: http://technet.microsoft.com/en-us/library/cc732930(WS.10).aspx

Что бы я предложил:

• Протестируйте локально на сервере разработки перед загрузкой любых изменений. Не вносите изменения на работающем сервере, пока вы не будете уверены, что он работает на тестовом сервере.
• Выполняйте техническое обслуживание при минимальном времени движения. Для большинства веб-сайтов это будет рано утром на выходных. Если выходные не подходят, то делайте это в течение вашего наименьшего количества трафика в течение недели.
• Предупредите пользователей о плановом обслуживании заранее.