Как выпускать веб-приложения?

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

Теперь, когда я создаю автономную версию, я буду выполнять фиксации в svn. Когда придет время для выпуска, я могу либо:

скопируйте код с автономного сервера во временный каталог на реальном веб-сервере, затем замените старую базу кода на новую (например, на ссылку) или...
У вас есть работающий веб-сервер, работающий над проверкой svn, и просто запустите обновление svn.

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

Каковы наилучшие методы для этой задачи?

Ответ 1

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

Раньше я использовал rsync для перемещения файлов между сценой и производством.

Мое типичное развертывание происходит следующим образом:

сайт для резервного копирования
Восстановление из резервной копии на сервер этапа
Блокировать сервер со всех внешних IP-адресов
Экспортируйте код из хранилища во временную папку (необязательно, чтобы разделить две папки для небольших изменений)
rsyc файлы из папки temp в папку сервера сценариев
Подтвердите, что только файлы, которые вы ожидали изменить, действительно изменились.
Применить SQL-скрипты к DB
Проверить обновление
Разблокировать веб-сервер

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

Ответ 2

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

Что вы можете подумать о том, что это промежуточный сервер. Вы выполняете локальные изменения, затем проверяете svn на промежуточном сервере и запускаете свои сценарии обновления. Вы проводите тест приёма на промежуточном сервере. Когда все будет хорошо, вы развертываете everhting на реальном сервере. Это должно быть так же просто, как запуск некоторых скриптов. то есть update-staging.pl и update-prod.pl.

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

Ответ 3

Я использую Capistrano до script и автоматизирует процесс развертывания. Здесь очертания того, что происходит, когда я вхожу cap deploy с моей локальной рабочей станции:

Капистрано.,

Оформить последнюю версию источника в каталоге с меткой времени (например, до /var/http/mywebsite.com/releases/20090715014527) на моем веб-сервере, предложив мне, если нужно, мою локальную рабочую станцию для любых паролей.
Запуск сценариев предварительной обработки (например, схема базы данных обновлений)
Сопряжьте ссылку на сайт в реальном каталоге:

ln -sf/var/http/mywebsite.com/releases/20090715014527/var/http/mywebsite.com/current
Запустите сценарии после обработки (например, возможно, вам нужно перезапустить apache или что-то еще)

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

Хотя Capistrano написан на Ruby, он может развертывать веб-приложения на любом языке/фреймворке. См. Раздел "Развертывание приложений без использования rails" в учебниках для идей. railsless-deploy кажется особенно полезным для использования Capistrano для управления развертыванием приложений PHP и Python.

Ответ 4

В теории я бы экспортировал svn в новую область на веб-сервере. Затем перенастройте веб-сервер для использования новой области и перезапустите.

Ответ 5

для небольших систем на основе php мы использовали следующее:

для изменения кода мы используем ant script, выполняемый из eclipse, который сравнивает локальную (dev) систему с удаленными (qa/prod/whatever) системами, затем застегивает все измененные файлы, scp zip на удаленной системы и разархивировать ее на цель. Конечно, у нас есть автоматическое резервное копирование и тому подобное. Если это интересно, я смогу опубликовать пример script в следующие несколько дней.

для sql-изменений мы стараемся поддерживать сценарии для каждого изменения (обычно в нашем отладчике ошибок) и вручную запускать каждое изменение в целевой системе.

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

обратите внимание, что если ваша система prod вытягивается непосредственно из svn, вы нарушаете изменения, которые, возможно, не были протестированы должным образом (вы можете забыть что-то совершить, проверить локальную систему, и все сломается в prod...)

Ответ 6

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