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

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

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

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

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

Capistrano будет. . .

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, он может развертывать веб-приложения на любом языке / среде. Идеи можно найти в разделе «Развертывание приложений, не являющихся rails» учебного руководства . railsless-deploy кажется особенно полезным для использования Capistrano для управления развертыванием приложений PHP и Python.

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

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

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

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

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

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

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