Подходят ли ежедневные сборки для веб-приложения?

Question

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

Немного о проекте, о котором я прошу -- Есть 2 разработчика, работающих над веб-приложением Django (Python).У нас есть 1 репозиторий svn.Каждый разработчик поддерживает проверку и свою собственную копию MySQL, работающую локально (если вы не знакомы с Django, он поставляется в комплекте со своим собственным тестовым сервером, во многом так, как приложения ASP могут запускаться внутри Visual Studio).Разработка и тестирование выполняются локально, а затем передаются обратно в репозиторий.Фактическая рабочая копия веб-сайта - это проверка SVN (я знаю об экспорте SVN, и это занимает слишком много времени).Самое близкое, что у нас есть к "сборке", - это пакетный файл, который запускает обновление SVN для рабочей копии, управляют ли биты django ('.py syncdb'), обновляет кэш поисковой системы (solr), затем перезапускает apache.

Я думаю, чего я не вижу, так это параллели с веб-приложениями.

Вы создаете веб-приложение с управлением исходным кодом и "ночными сборками" - если да, то как это выглядит?

Answer 1

Вы можете легко запускать все свои модульные тесты Django через среду тестирования Django как свою ночную сборку.

Вот что мы делаем.

У нас также есть несколько обычных модульных тестов, которые не используют возможности Django, и мы их тоже запускаем.

Даже несмотря на то, что Python (и Django) не требуют того типа ночного теста компиляции / компоновки / модульного тестирования, который делают скомпилированные языки, вы все равно получаете пользу от ежедневной дисциплины «Не ломай сборку». И ежедневный цикл юнит-тестирования всего, что у вас есть, - это хорошо.

Мы находимся в процессе рассмотрения Python 2.6 (который отлично работает для нас) и запуска наших модульных тестов с опцией -3 , чтобы увидеть, какие устаревшие функции мы используем. Наличие полного набора модульных тестов гарантирует нам, что изменение совместимости с Python 3 не нарушит сборку. И запускать их по ночам означает, что мы должны быть уверены , что мы правильно рефакторинг.

Answer 2

Непрерывная интеграция полезна, если у вас есть правильные процессы вокруг нее. TeamCity от JetBrains - отличная отправная точка для знакомства:

http://www.jetbrains.com/teamcity/index.html

Здесь есть отличная статья, которая имеет прямое отношение к Джанго:

http://www.ajaxline.com/continuous-integration-in -django-проект

Надеюсь, это поможет вам.

Answer 3

Веб-приложения, построенные на динамических языках, могут не требовать "компиляции" шаг, но все равно может быть несколько «сборок» шаги, необходимые для запуска приложения. Сценарии сборки могут устанавливать или обновлять зависимости, выполнять миграцию базы данных, а затем запускать набор тестов, чтобы убедиться, что код «чистый». w.r.t. актуальная зарегистрированная версия в репозитории. Или вы можете развернуть копию кода на тестовом сервере, а затем запустить набор интеграционных тестов Selenium для новой версии, чтобы убедиться, что функциональность основного сайта все еще работает.

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

Answer 4

Если над этим действительно работаете только вы и еще один разработчик, ночные сборки, вероятно, мало что вам дадут.

Я бы сказал, что эквивалентом ночных сборок веб-приложений были бы промежуточные сайты (которые можно создавать по ночам).

Когда ночные сборки в промежуточной зоне начинают приносить реальные дивиденды, у вас есть клиенты, менеджеры проектов и специалисты по контролю качества, которым необходимо иметь возможность видеть актуальную, но относительно стабильную версию приложения.Ваши песочницы разработчика (по крайней мере, если вы похожи на меня), вероятно, проводят много времени в непригодном для использования состоянии, поскольку вы что-то ломаете, пытаясь реализовать следующую функцию.Итак, типичная проблема заключается в том, что специалист по контролю качества хочет убедиться, что ошибка исправлена, или PM хочет проверить, что какая-то запланированная функция была реализована правильно, или клиент хочет увидеть, что вы добились прогресса в решении проблемы, которая его волнует.Если у них есть доступ только к "песочницам разработчика", есть большая вероятность, что, когда они посмотрят на это, либо версия "песочницы" не запущена (поскольку это означает ./manage.py runserver запущен где-то в терминале) или он находится в нерабочем состоянии из-за чего-то другого.Это действительно замедляет работу всей команды и отнимает уйму времени.

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

Итак, в заключение, установка, в которой я работаю:

• каждый разработчик запускает свою собственную песочницу локально (так же, как это делаете вы).
• на сервере разработки есть "обычная" промежуточная песочница, которая обновляется каждую ночь из cronjob.Туда направляются руководители, клиенты и отдел контроля качества.Им никогда не предоставляется прямой доступ к песочницам разработчика.
• Существует автоматизированное (хотя и инициируемое вручную) развертывание на производстве.Разработчик или премьер-министр могут "подтолкнуть" к производству, когда мы почувствуем, что все прошло достаточный контроль качества и является стабильным и безопасным.

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

Answer 5

Я добился большого успеха, используя Hudson для непрерывной интеграции. Подробная информация об использовании Hudson с Python. Redsolo .

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

Answer 6

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