Практики при выпуске веб-приложений на основе python/ruby/script в производство

Я чисто Windows-программист и трачу все свое время на взлом VC++.

Недавно я руководил несколькими веб-приложениями и сам создавал приложения с помощью python (/pylons framework) и выполнял проекты на рельсах. Все веб-проекты размещены на Ubuntu Linux.

Процедуры RELEASE и контрольный список, которым мы следовали при создании и выпуске оконного приложения VC++, просто бесполезны, когда речь идет о языке, основанном на сценариях.

Так что сейчас мы не создаем двоичные файлы. Я скопировал файлы asp/php в папку IIS через сервер ftp при использовании приложений cms с открытым исходным кодом.

Таким образом, FTP — это один из способов размещения файлов на веб-сервере. Теперь нам лень или не очень хочется копировать файлы через ftp, вместо этого мы используем SVN checkout и просто делаем svn update, чтобы получить последнюю копию.

Является ли проверка SVN и обновление svn правильными методами для обновления последних файлов сборки на сервере? Есть ли недостатки в использовании svn update? Есть ли лучший способ выпуска сценариев/веб-сценариев на производственный сервер?

PS: я использовал ssh-сервер с некоторым расширением на платформе Linux.


python ruby linux release scripting
person Community    schedule 13.01.2010    source источник

Ответы (4)


arrow_upward
3
arrow_downward

Я бы создавал ветку в SVN для каждого релиза веб-приложения и когда релиз там был бы готов, я бы проверял его на сервере и ставил на запуск или перемещал на место старой версии.

person gruszczy    schedule 13.01.2010
comment
это один хороший совет. Я всегда обновлял багажник и вызывал небольшие проблемы - person ; 13.01.2010
comment
Дополнительным способом расширения этой стратегии может быть сохранение старых версий приложения на сервере для аварийного восстановления и обновление ссылки из новой версии кода на «текущий» каталог, который фактически обслуживает приложение. - person Adam Crossland; 13.01.2010
comment
Адам, ты понял мою еще одну ошибку. это произошло в моем приложении. - person ; 13.01.2010
comment
Если вы выполняете развертывание непосредственно из svn (опрометчиво), вы действительно хотите выполнять это развертывание из тега, а не из ветки. В приличной установке svn хук предотвратит изменение тега. вы знаете, что производство соответствует этому тегу. если вы развертываете из ветки, вы должны помнить, какая ревизия в этой ветке - кто-то может зарегистрироваться после вашего развертывания, тогда вы переходите на новую ветку, в которой есть проблемы... возврат к предыдущей ветке не ставит вы в предыдущем состоянии. - person thekbb; 15.12.2010

arrow_upward
2
arrow_downward

Является ли проверка SVN и обновление svn правильными методами для обновления последних файлов сборки на сервере?

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

Есть ли недостатки в использовании svn update? Никто.

Есть ли лучший способ выпуска сценариев/веб-сценариев на производственный сервер?

Что мы делаем.

У нас не заканчиваются каталоги проверки SVN. Каталог проверки SVN является «сырым» исходным кодом, расположенным на сервере.

Мы используем setup.py install Python для создания приложения в дереве каталогов /opt/app/app-x.y. Каждая помеченная ветвь SVN также является ветвью в окончательной установке.

У Ruby есть гемы и другие инструменты установки, которые, вероятно, похожи на Python.

Конфигурации Apache и mod_wsgi нашего веб-сайта относятся к конкретной /opt/app/app-x.y версии. Затем мы можем подготовить версию, провести тестирование, выполнить такие действия, как перенос данных из рабочей среды в следующую версию, и в целом подготовиться.

Затем мы настраиваем нашу конфигурацию Apache и mod_wsgi для использования следующей версии.

Предыдущие версии все на месте. И оставил на месте. Когда-нибудь мы их удалим, когда они нас смутят.

person S.Lott    schedule 13.01.2010

arrow_upward
2
arrow_downward

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

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

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

Я также хотел бы добавить, что хотя мы не "строим" (компилируем) проект на динамических языках, мы "строим" (тестируем/интегрируем) их. Серьезный проект должен использовать сервер непрерывной интеграции для проверки интегрированной "сборки" проекта на каждом зафиксировать или интегрировать задолго до того, как он попадет в производство.

person hgmnz    schedule 13.01.2010

arrow_upward
0
arrow_downward

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

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

person thekbb    schedule 15.12.2010