Ежедневно строит путь для веб-приложения?
Джоэл, кажется, высоко ценит ежедневные сборки. Для традиционного скомпилированного приложения я, конечно, вижу его обоснование, но как это соотносится с веб-разработкой - или нет?
Немного о проекте, о котором я спрашиваю - над веб-приложением Django (Python) работают 2 разработчика. У нас есть 1 хранилище SVN. Каждый разработчик поддерживает проверку и свою собственную копию MySQL, работающую локально (если вы не знакомы с Django, он поставляется в комплекте с собственным тестовым сервером, во многом способ, которым приложения ASP могут работать внутри Visual Studio). Разработка и тестирование выполняются локально, а затем передаются обратно в хранилище. Фактическая рабочая копия сайта - проверка SVN (я знаю об экспорте SVN, и это занимает слишком много времени). Ближе всего к "сборке" мы имеем пакетный файл, который запускает SVN-обновление для рабочей копии, выполняет биты django ('manage.py syncdb'), обновляет кэш поисковой системы (solr), а затем перезапускает apache.
Я думаю, что я не вижу параллели с веб-приложениями.
Делаете ли вы веб-приложение с контролируемым исходным кодом с "ночными сборками" - если да, то как это выглядит?
6 ответов
Вы можете легко запустить все свои модульные тесты Django через среду тестирования Django в качестве ночной сборки.
Это то, что мы делаем.
У нас также есть несколько обычных модульных тестов, которые не используют возможности Django, и мы их тоже запускаем.
Даже несмотря на то, что Python (и Django) не требуют того типа ночного теста компиляции / линковки / модульного тестирования, который делают скомпилированные языки, вы все равно выигрываете от ежедневной дисциплины "Don't Break The Build". И ежедневный цикл юнит-тестирования всего, что у вас есть, - это хорошо.
Мы находимся в процессе рассмотрения Python 2.6 (который отлично работает для нас) и запуска наших модульных тестов с -3 возможность увидеть, какие устаревшие функции мы используем. Наличие полного набора модульных тестов гарантирует нам, что изменение совместимости с Python 3 не нарушит сборку. И запускать их по ночам означает, что мы должны быть уверены, что мы правильно рефакторинг.
Веб-приложения, созданные на динамических языках, могут не требовать шага "компиляции", но все же может быть несколько шагов "сборки", необходимых для запуска приложения. Ваши сценарии сборки могут устанавливать или обновлять зависимости, выполнять миграцию базы данных, а затем запускать набор тестов, чтобы убедиться, что код "чистый" относительно фактической зарегистрированной версии в хранилище. Или вы можете развернуть копию кода на тестовом сервере, а затем запустить набор интеграционных тестов Selenium для новой версии, чтобы убедиться, что функциональность основного сайта все еще работает.
Это может помочь немного почитать тему непрерывной интеграции, которая очень полезна для команд разработчиков веб-приложений. Чем быстрее и динамичнее идет процесс разработки, тем больше вам требуется регулярного ввода данных от автоматизированного тестирования и показателей качества, чтобы обеспечить быструю и громкую неудачу в любой испорченной версии кода.
Непрерывная интеграция полезна, если у вас есть правильные процессы вокруг нее. TeamCity от JetBrains - отличная отправная точка для знакомства:
http://www.jetbrains.com/teamcity/index.html
Здесь есть отличная статья, которая напрямую связана с Джанго:
http://www.ajaxline.com/continuous-integration-in-django-project
Надеюсь, это поможет вам начать.
Если на самом деле над вами работают только вы и еще один разработчик, то ночные сборки, вероятно, не принесут вам особой пользы.
Я бы сказал, что эквивалентом ночных сборок в веб-приложении будут промежуточные сайты (которые могут создаваться ночью).
Ночные сборки в промежуточной зоне начинают приносить реальные дивиденды, когда у вас есть клиенты, менеджеры проектов и специалисты по обеспечению качества, которым необходимо видеть обновленную, но относительно стабильную версию приложения. Ваши песочницы разработчика (если вы похожи на меня, по крайней мере), вероятно, проводят много времени в непригодном для использования состоянии, когда вы ломаете вещи, пытаясь реализовать следующую функцию. Таким образом, типичная проблема заключается в том, что специалист по обеспечению качества хочет проверить, исправлена ли ошибка, или премьер-министр хочет проверить, что какая-то запланированная функция была реализована правильно, или клиент хочет увидеть, что вы достигли прогресса в решении проблемы, которая его волнует. около. Если у них есть доступ только к песочницам разработчика, есть хороший шанс, что когда они увидят его, либо версия песочницы не работает (так как это означает, что./manage.py runserver где-то в терминале), либо в сломанном состоянии из-за чего-то еще. Это действительно тормозит всю команду и тратит много времени.
Похоже, у вас нет промежуточной настройки, поскольку вы просто автоматически обновляете рабочую версию. Это может быть хорошо, если вы более осторожны и дисциплинированы, чем я (и я думаю, что большинство разработчиков), и никогда не делаете ничего, что не является полностью пуленепробиваемым. Лично я предпочел бы удостовериться, что моя работа прошла через хотя бы некоторый поверхностный контроль качества кем-то кроме меня, прежде чем она попадет в производство.
Итак, в заключение настройки, где я работаю:
- каждый разработчик запускает свою собственную песочницу локально (так же, как вы это делаете)
- на сервере разработчиков есть "обычная" промежуточная песочница, которая обновляется каждую ночь с помощью cronjob. ПМ, клиенты и QA идут туда. Им никогда не предоставляется прямой доступ к песочницам разработчиков.
- Существует автоматическое (хотя и инициированное вручную) развертывание в производство. Разработчик или руководитель проекта могут "подтолкнуть" к производству, когда мы чувствуем, что все в достаточной степени проверено и стабильно и безопасно.
Я бы сказал, что единственным минусом (помимо небольшого количества дополнительных затрат на настройку ночных сборок) является то, что это делает день исправления ошибок. т. е. QA сообщает об ошибке в программном обеспечении (основываясь на просмотре ночной сборки этого дня), разработчик исправляет ошибку и фиксирует ее, затем QA должен подождать до сборки следующего дня, чтобы убедиться, что ошибка действительно исправлена. Обычно это не такая большая проблема, так как у каждого достаточно вещей, которые не влияют на график. Когда приближается веха, и мы находимся в замороженном режиме, только для исправления ошибок, мы будем чаще обновлять промежуточный сайт вручную.
Я имел большой успех, используя Hudson для непрерывной интеграции. Подробная информация об использовании Hudson с Python от Redsolo.
Несколько месяцев назад несколько статей, поддерживающих непрерывное развертывание, вызвали настоящий ажиотаж в Интернете. IMVU имеет подробную информацию о том, как они развертываются до 5 раз в день.
Основная идея частых сборок (ночных или более частых, как в случае непрерывной интеграции) состоит в том, чтобы получить немедленную обратную связь, чтобы сократить время, прошедшее между появлением проблемы и ее обнаружением. Таким образом, сборка часто полезна только в том случае, если вы можете генерировать некоторую обратную связь с помощью компиляции, (в идеале, автоматизированного) тестирования, проверок качества и т. Д. Без обратной связи в этом нет никакой реальной необходимости.