развернуть сайт из системы контроля версий - экспорт и символические ссылки?

Question

Я одинокий разработчик. У нас есть несколько сайтов, размещенных на веб-хостинге. Репозиторий SVN также находится на веб-хосте. В доме у нас есть машина для разработки, которая является достаточно близкой копией живой среды.

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

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

Это переусердствует? Каковы другие способы сделать это?

Answer 1

Есть Capistrano, который помогает вам в этом процессе. Использование SSH и ключей делает процесс развертывания изменений и т. Д. Довольно простым. Хотя это приложение ruby, вы все равно можете использовать его для развертывания PHP или других приложений, посмотрите здесь для получения дополнительной информации

И эта статья говорит об этом, используя общую папку вместе с вашей папкой выпуска. В общей папке могут храниться файлы конфигурации для вашего отдельного сервера развертывания (URL-адрес, соединение с БД и т. Д.), А также ресурсы, которые загружаются в течение жизни веб-сайта и отсутствуют в svn. Вы можете сделать так, чтобы Capistrano справился и с вами.

Хотя кто-то, кто не знает настройки, может сначала столкнуться с некоторыми сложностями, это действительно облегчает развертывание. Я думаю, что Capistrano делает довольно просто и, вероятно, может быть написан на другом языке, чтобы справиться с вашим конкретным сценарием.

И еще одна идея связать это с SVN или любым хранилищем. Это использовать их хуки для выполнения этих развертываний. т.е. каждый коммит на транк будет обновлять сервер разработки. И ветвь подтолкнет его к вашей промежуточной среде.

Но эта ссылка отлично показывает, как настроить окружение такого типа. Я думаю, что вы создали хорошую практику и не сделали достаточно. Единственное, что может вам помочь, - это автоматическое развертывание в различных средах и сценариях, помогающее настроить новое развертывание.

Обновление ::
Кроме того, я хотел бы отметить, что SVN может обрабатывать символические ссылки. Поэтому, если вы выполняете развертывание на серверах на основе Unix, вы можете просто вставить символические ссылки в свой репозиторий и использовать относительную символическую ссылку.

Так что, если у вас есть

./releases/200912231043
./shared/uploads

Вы можете поставить символическую ссылку как

./releases/200912231043/uploads -> ../../shared/uploads

Это даст вам простой способ управления активами, не входящими в svn, без использования большого количества сценариев, которые можно развернуть. Теперь вы можете просто использовать коммит для развертывания на вашем устройстве разработки и / или организации.

Answer 2

Это то, что я делал в последние пару лет для нескольких проектов, и никогда не было ни одной проблемы с этим способом.

Возможность «отката» с символическими ссылками может показаться немного излишним, да ... Но в тот день, когда вам понадобится сохранить сайт, на котором вы развернули версию с критической ошибкой, вы действительно оцените это способность!
Я использовал это примерно 2 раза за 3 года - но каждый раз это действительно спасало день ^^

Однако мне кажется странным одно: если я правильно понимаю, вы тестируете новую версию веб-сайта в реальной (производственной) базе данных?

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

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

Кроме того: вы делаете много тестов, и это хорошо ... Но почему бы не автоматизировать некоторые из них?

Это позволит вам тестировать быстрее, чаще, и вы будете тратить меньше времени на тестирование и больше времени на разработку; -)

Answer 3

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

Какой у вас вопрос? Вы не уверены в чем-то? Разве это не работает для вас? Если да, то какая именно часть?