Рано или поздно растущий проект требует все новых и новых «фич», порой требующих вмешательства непосредственно в жизненно важные части сайта, например базу данных, систему авторизации пользователей или принцип формирования url страниц.
При внедрении таких изменений, в частности в веб-приложения имеющие уже обширную аудиторию или систему в которой люди зарабатывают или тратят деньги требует ответственного подхода.
Во время разработки двух серьезных проектов: один это система доставки товаров из США в Европу, другой система калькуляции налогов на товары ввозимые из одной страны в другую. Процесс внедрения обновлений был следующий.
1) На работающем проекте создавалась полная копия сайта, но выносилась она на отдельный домен, можно поддомен. Естественно закрывалось это все от индексации, та же самая http авторизация подходит как нельзя кстати.
2) Далее, создаем на сервере еще одну базу данных и заливаем туда базу нашего рабочего сайта.
3) Проверяем получили ли мы точную копию нашего сайта. Если нет, сносим все файлы, базу и заново с пункта 1.
4) Заливаем все наши обновления: файлы, выполняем все запросы.
5) Проверяем работоспособность нового сайта. Если все хорошо, повторяем пункт 4 на работающем сайте. В обратном случаем, заново сносим базу и все файлы, ищем ошибки в новом функционале, исправляем их и заново по списку, начиная с пункта 1.
Эти действия тривиальные, но зачастую муторные — возможно, при копировании сайта вам поможет статья о переносе сайта на новый хостинг. По сути вы делаете тоже самое.
Данный способ внедрения нового функционала подходит для тех сайтов, которые желательно не выключать на технического обслуживание 🙂
Я бы только посоветовал делать всё на ссылках, пусть будут папки с версиями сайта, а documment_root — линк на последнюю оттестированную на боевом хостинге версию. тогда переключение делается мгновенно. ну и некоторые файлы даже в тестируемой версии могут быть ссылками, например общие конфиги, папка с пользовательскими данными. мы по такой схеме накатывали апдейты на живые аукционы, которые нельзя останавливать.
Да тоже хороший способ, своеобразная система контроля версий. Как-нить под пиво расскажу как это организовано у MTV, там вообще система умом тронутся, но вероятность что не зальешь шило 100%.
я уже готов угостить тебя пивом, а то даже на конференциях (недавно был на di + devcamp) у нас о таких вещах не говорят :(. Приходится инфу по крупицам в интернетах собирать и самому велосипеды делать.
ну следующей неделе я думаю организуемся как-нибудь 🙂 если честно по мне di это просто повод самополбоваться для участвников, мол какие мы молодцы, как-то даже желания не появлялось побывать там, может я не права правда, зиссера увидеть дорогого стоит 🙂
По мне, так такой вариант не всегда удобен. Я прекрасно помню, как я перепрыгивал с WordPress версии 2.0.9 на версию 2.1-2.3.3 ,так проблема например WP, в том, что в его конфигах идёт привязка к домену. Т.о. просто «переключить» не получается. Потому как приходиться перековыривать всю базу, в поисках домена и всё это приходилось делать вручную. Не знаю как с обновлением WP (ну например с версии 2.3 на 2.9 или даже на 3) обстоят дела сейчас, но на момент, когда мне понадобилось, была именно такая проблема. Как я понял с джумлой такая же фигня.
p.s. мои собственные проекты и наработки не привязаны к домену и вообще я считаю, что это плохая практика. Привязка не нужна никому, ну разве что в случаях, если нужно защитить свой скрипт, но это уже совсем другая история…
Ну и привязка к домену также решается, например через изменени файла hosts:
делаете запись
site.com 124.125.1.2
где 124.125.1.2 тестового сервера и все, теперь набрав site.com попадете на тествый по тому же адресу
обновление сайта мне кажется настолько сложным делом, что даже не хочется за это браться!
Рано или поздно придется, или обновлять или отдавать пользователей в пользу более современных проектов
О, друг, спасибо за статью!!!!! Очень нужная информация!!!