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

Question

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

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

1. скопируйте код с автономного сервера во временный каталог на работающем веб-сервере, а затем замените старую кодовую базу на новую (например, со ссылкой), или ...
2. сделайте так, чтобы живой веб-сервер работал на svn checkout, и просто запустите svn update.

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

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

Answer 1

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

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

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

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

Теперь, чтобы развернуть в производство, повторите эти шаги в ускоренном режиме. Использование сценариев делает это намного проще.

Answer 2

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

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

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

Answer 3

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

Капистрано будет. , ,

1. Извлечение последней версии источника в каталоге с меткой времени (например, /var/http/mywebsite.com/releases/20090715014527) на моем веб-сервере, при необходимости запрашивая у меня @ моей локальной рабочей станции любые пароли.

2. Запуск сценариев предварительной обработки (например, обновление схемы базы данных)

3. Мягкая ссылка сайта в действующий каталог:

   ln -sf /var/http/mywebsite.com/releases/20090715014527 /var/http/mywebsite.com/current

4. Запуск сценариев постобработки (например, может быть, вам нужно перезапустить apache или что-то еще)

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

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

Answer 4

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

Answer 5

для небольших систем на основе php, что мы привыкли делать так:

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

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

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

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

Answer 6

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