localhost + постановка + производственная среда? - PullRequest
5 голосов
/ 29 декабря 2010

У меня есть сайт www.livesite.com, работающий в данный момент.Я занимаюсь разработкой новой версии веб-сайта на своем локальном компьютере с http://localhost, а затем фиксирую свои изменения с помощью svn на www.testsite.com, где я буду тестировать сайт на сервере LiveSite.com, но в другом домене.(это та же среда, что и на живом сайте, но в другом домене).

Теперь я готов выпустить новую версию на сайтеitesite.com.Сделать это в первый раз легко, я мог бы просто скопировать и вставить все с testsite.com наlifeite.com (не уверен, что это лучший способ сделать это).

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

Я также хочу сохранить свою историю SVN на testsite.com.Как правильно сделать это с SVN?Большое вам спасибо!

Ответы [ 3 ]

5 голосов
/ 29 декабря 2010

Другие ответы, в которых упоминаются Хадсон или Веплой, хороши.Они охватывают больше вопросов, чем то, что следует.Тем не менее, следующего может быть достаточно:

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

Сделайте ваш документ гордости корнемсимволическая ссылка, а не фактический каталог.Это означает, что у вас есть что-то вроде этого:

/var/www/myproject-1-0-0
/var/www/myproject-1-1-0
/var/www/myproject-1-1-1
/var/www/html -> myproject-1-1-1

Это означает, что вы можете извлекать код в производство (скажем, myproject-1-1-2) без перезаписи обслуживаемого материала.Затем вы можете почти мгновенно переключать кодовые базы, выполняя что-то вроде:

$ rm html && ln -s myproject-1-1-2 html

Я бы порекомендовал не делать svn checkout / svn export вашего транка в рабочей коробке.Вместо этого создайте ветку заблаговременно (назовите ее как myproject-XYZ).Таким образом, если вам нужно сделать очень напряженную настройку производственного кода, вы можете зафиксировать его обратно в ветку и объединить его с магистралью после того, как пожар погас)

Я делаю это много, и этоработает довольно хорошо.Тем не менее, у него есть несколько существенных недостатков:

В основном, вы должны самостоятельно выполнять миграцию базы данных или другие сценарии обновления.Если у вас есть сценарии (обычный старый SQL или что-то более сложное), вам нужно подумать о том, как лучше всего их выполнять.Время простоя с надеждой на одну минуту не может быть плохой идеей.Вы можете сохранить «сайт технического обслуживания» (/ var / www / mainenance) и указать на него символическую ссылку на несколько минут, если вам нужно.

Этот метод не такой крутой, как, например, Weploy, но для относительно небольших проектов (запущенных на одном сервере с небольшими базами данных) это часто достаточно хорошо и очень просто.

2 голосов
/ 29 декабря 2010

Мой ответ немного усложнит ситуацию, но здесь идет речь:

Я бы для этого сценария использовал Хадсон .

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

Предостережение заключается в том, что вам нужно немного узнать о том, как настроить Хадсона и как его настроить 1018* работа для вас.

Как начать работу с PHP для Hudson

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

1 голос
/ 29 декабря 2010

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

Во всех случаях и независимо от того, используете ли вы какой-либо инструмент непрерывной интеграции, яПолагаю, что безопаснее всего пойти на простоя, чтобы применить эти изменения.Одна из причин, по которой люди размещают на своих сайтах стикер «бета», заключается в том, что они могут отключить всех и запретить их применение без уведомления.Пока они не делают это очень часто, им это тоже сойдет с рук.Как только вы выйдете из бета-версии, применение изменений станет церемонией, когда вы начнете объявлять время простоя заранее за недели, а затем получите окно от 30 минут до нескольких часов, чтобы применить все изменения.

Для таких базовых вещей, как исправление недостатков безопасностив ОС или системном программном обеспечении, добавлении аппаратного обеспечения и т. д. можно избежать простоев при балансировке нагрузки и применении исправлений по одному.

...