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

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

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

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

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

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


release svn
person Stefano Borini    schedule 11.08.2009    source источник
comment
Стефано, ты считаешь мой ответ хорошим?   -  person TheJacobTaylor    schedule 16.03.2010
comment
@TheJacobTaylor: Я принимаю сеансы каждые пару недель. В эти выходные я перечитаю все ответы и приму.   -  person Stefano Borini    schedule 16.03.2010

Ответы (6)


arrow_upward
10
arrow_downward

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

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

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

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

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

person TheJacobTaylor    schedule 11.08.2009
comment
Я согласен, но если у вас много файлов, экспорт svn может быть МЕДЛЕННЫМ! - person Byron Whitlock; 11.08.2009
comment
На большинстве веб-серверов тривиально настроить фильтр, который не позволяет ему обслуживать папки .svn, поэтому я бы не стал рассматривать это как причину против использования svn update. Однако об этом следует помнить при первой настройке сервера. - person rmeador; 11.08.2009
comment
ну, в общем, скорость не проблема, если вы экспортируете из локального (дискового или сетевого) svn. либо это ? Я имею в виду, что svn не быстр. отнюдь не. - person Stefano Borini; 11.08.2009
comment
Хорошая точка зрения на фильтры веб-сервера. К сожалению, я обнаружил, что люди часто забывают, почему все настроено определенным образом, а затем изменяют их позже, чтобы повысить безопасность или что-то в этом роде. Если вы публикуете папки, содержащие ваши материалы SVN, убедитесь, что у вас есть простая программа, которая проверяет, что они все еще заблокированы. Недавно я столкнулся с регрессом, когда файлы журналов публиковались из-за такого рода проблем. Если SVN работает медленно, вы можете выполнить локальный экспорт, а затем оттуда выполнить rsync. К счастью, rsync работает быстро. - person TheJacobTaylor; 12.08.2009
comment
SVN становится медленнее, чем больше вы его используете. Чтобы воссоздать файл, я считаю, что он должен пройти через все ревизии файла, исправляя его, чтобы добраться до текущей версии. Для репозиториев с большим количеством изменений в файле это может быть довольно болезненно. В последнее время я использую и люблю GIT. Он хранит последнюю версию и может сразу ее получить. - person TheJacobTaylor; 16.03.2010

arrow_upward
4
arrow_downward

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

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

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

person Byron Whitlock    schedule 11.08.2009
comment
действительно, я также пишу сценарии отката, когда это возможно. Я не знаю, насколько это полезно, поскольку я не буду повторно вставлять данные, но, по крайней мере, у меня будет способ понизить версию структуры SQL, на всякий случай. - person Stefano Borini; 11.08.2009

arrow_upward
3
arrow_downward

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

person Pete    schedule 11.08.2009

arrow_upward
1
arrow_downward

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

person grigy    schedule 11.08.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

person Nir Levy    schedule 11.08.2009
comment
насчет zip: а как насчет удаления старых файлов? +1 за последнее замечание. Меня укусили. - person Stefano Borini; 11.08.2009
comment
на самом деле, я все время храню старые zip-файлы. Я называю их yyyymmddhhmiss.zip, чтобы я всегда мог точно знать, какой код был помещен в продукт, и когда именно, и могу даже (болезненно) вернуться к старым версиям, если мои резервные копии не удаются. Я удаляю их только тогда, когда у меня заканчивается место на диске. - person Nir Levy; 11.08.2009

arrow_upward
1
arrow_downward

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

person baudtack    schedule 11.08.2009