Я смотрю на Django [http://www.djangoproject.com/], и вся система, похоже, поддерживает развертывание через SVN. Документация предупреждает вас, когда вы не читаете из магистрали SVN; а люди в #django утверждают, что механизм SVN легче использовать.
Я интуитивно предпочитаю, чтобы Django был доступен в apt-get и получать обновления через эти Ubuntu LTS. Я получаю некоторую экспертную оценку, автоматическое развертывание и версии зависимостей. Эти люди сумасшедшие, или я что-то упускаю?
Запускать его из svn совершенно разумно. Теперь запускать его из ствола svn нет. Вообще.
Как узнать, что у вас запущено, если вы на стволе? Нет, запустите машины для разработки и тестирования на магистрали. Когда вы будете готовы к выпуску, сделайте это, отметив все. Обновите промежуточный сервер до этих новых тегов и проверьте. Если все в порядке, обновите и рабочий сервер.
Это не имеет значения, будь то ваш svn-сервер или кто-то еще.
Я должен сказать, что запуск веб-приложения из вашего СОБСТВЕННОГО репозитория SVN довольно разумно (хотя вам нужно быть осторожным с тем, что вы делаете!), Но запуск его из чужого репозитория SVN, вероятно, вызывает проблемы. Возможно, вам захочется создать локальный репозиторий, который является своего рода «закрытым зеркалом» официального. Вы можете подключить официальные источники к ветке, протестировать их, а затем переместить их в ствол (или что-то еще), когда вы в них уверены.
Мое единственное реальное возражение заключается в том, что вы (как человек, который должен поддерживать работу веб-приложения) не имеете никакого контроля над репозиторием Django SVN. По крайней мере, с пакетами Ubuntu у вас есть некоторая уверенность в том, что кто-то, кроме разработчика, просмотрел его и нашел, что он, по крайней мере, частично стабилен. И сначала обновить тестовую систему просто.
Я столкнулся с аналогичной ситуацией с TurboGears, другим веб-фреймворком на основе Python. Я начал с упакованных версий Debian, установленных, как вы описали, с помощью apt-get. Однако я довольно быстро обнаружил, что мир веб-разработки развивается намного быстрее, чем процесс упаковки и выпуска Debian. Ubuntu в этом отношении немного лучше, но только если вы обновляетесь до каждой новой версии и не придерживаетесь версий LTS.
Мое решение состояло в том, чтобы использовать virtualenv чтобы создать виртуальную установку Python для каждого основного приложения, а затем использовать easy_install setuptools для установки последней выпущенной версии необходимых библиотек Python из репозиториев pypi. Это не идеально, поскольку было бы намного лучше использовать единую систему управления программным обеспечением, но это позволило нам отслеживать последние версии важных пакетов, не загрязняя основные версии системы, установленные Debian / Ubuntu.
Этот подход кажется более безопасным, чем использование прямой проверки SVN, которая может выйти из строя в любой момент из-за неправильной фиксации. Это означает, что вы немного отстали от передового края, но, вероятно, это то, что вам нужно для производственного сервера.
Запуск из SVN (или другого сервера управления версиями) имеет смысл, если вы используете выпущенные ветки. Это гарантирует, что критические обновления безопасности, которые происходят с веб-приложениями со сценариями гораздо чаще, чем с бинарными приложениями, применяются чаще. Поскольку большинство клиентов используют SVN для загрузки обновлений веб-приложений, вы часто обнаружите, что репозитории apt-get (или другие репозитории распространения) обновляются реже, и вы упустите новые функции и исправления безопасности. Кроме того, поскольку веб-приложения имеют тенденцию быстро «видоизменяться» и часто вводить обновления, нарушающие обратную совместимость, когда пакет наконец обновится, у вас будет больше шансов, что ваше конкретное приложение сломается.
Например, текущая версия Apache 2.2.11 выпущена в декабре прошлого года. IIRC, мой единственный сервер Ubuntu, на котором размещено одно конкретное приложение, работает под управлением 2.2.8. Кажется, я не могу найти удобную таблицу дат выпуска в ветке httpd-2.2, но на сайте архива указано, что changes-2.2.8 был опубликован в начале 2008 года. В тот же период ствол Zend Framework вырос с 50 тысяч строк. кода за 20 миллионов строк кода.
На вашем месте я бы использовал svn: externals с базовым пакетом, а затем добавил бы ваши собственные модификации в репозиторий Subversion и был бы в курсе предупреждений безопасности, касающихся любых зависимостей вашего веб-приложения. Если вы используете непрерывную интеграцию, вы можете запускать тестовые наборы в своей среде и с вашими изменениями, чтобы вы знали, когда различные магистрали и ветви устойчивы к вашим конкретным применениям, и могли обновлять по желанию при обнаружении уязвимостей безопасности.
Мы запускаем собственное веб-приложение (CMS) на рабочей копии SVN. Это значительно упрощает его обновление из репозитория, и если мы внесем изменение, которое хотим зафиксировать, мы легко сможем это сделать. Пока проблем нет.
Я предпочитаю локальные ветки, поскольку у SVN нет возможности локальных коммитов, я обычно использую git-svn.
Позвольте мне легко выполнить проверку работоспособности с помощью восходящего канала SVN (или соответствующего тега / ветки), а затем зафиксировать в моем (site-) локальном репо, с которого начинается реальное развертывание.
Примечание: мне было нелегко привыкнуть к git (около 2 недель), и я все еще сталкиваюсь с некоторыми незначительными проблемами (не спрашивайте меня, почему, но возвращение все еще является чем-то, когда я стреляю себе в ногу), но превосходные функции стоит того каждый раз.
С другой стороны, вы можете поладить с svn externals, я не уверен, можно ли использовать определенные версии с svn externals, но это может работать для определенного механизма обновления.