Pull to refresh

Comments 16

Я бы поставил двоеточие. How to: continuous integration…
А я в свое время TeamCity не осилил, что-то coverage не получилось настроить, хотя Jenkins'ом сейчас доволен.
Спасибо за топик!
а у меня обратная ситуация. дженкинс не создал файлы конфигурации там где должен (если верить документации) после установки, а разбираться стало лень. :) рад что оказался полезен!

Здесь я бы ограничил 1. Я подозреваю что в БД при одновременном запуске нескольких тестов могут начнаться конфликты данных и билды запросто не пройдут.
Да, но я не стал углубляться в тонкости правильного конфигурирования всех параметров (тем более что у меня — я единственный коммитер, а писал я мануал со своей ситуации), портянка и так длинная. Целью было минимально настроить и поднять все компоненты чтобы автоматом собиралось и тестилось. Думаю про нюансы настройки можно накропать ещё не один такой рулон писанины…
БД для тестов лучше всего указать in-memory sqlite, это гораздо быстрее
Мне кажется это совсем уж спорный вопрос, особенно, если учитывать, что мы тут даже виртуальное окружение проверяем на работоспособность — мало ли чего там в реализации не так. Вдруг оно будет пахать в памяти, а на планируемом мускуле не полетит? Миграции не промигрируются?

Понятно что быстрее, но я лично от греха подальше пускаю тесты в той же СУБД что будет на боевой системе…
Для тех кому пока кажеться, что решение вроде TeamCity/Jenkins слишком громоздки и неоправданы для вашего не очень большого проекта — рекомендую посмотреть на nosy. Это автоматическая запускалка тестов через nose, которая перезапускает все тесты при измении файлов проекта. Очень удобно запускать в соседнем окне и мгновенно видеть прогрес после очередного сохранения текущего файла.
У nose очень хитрый загрузчик модулей с тестами, и в результате возможны ситуации когда стандартный ./manage.py test работает, под вебсервером работает, а nose тесты падают.

В частности у меня была проблемы со всяческими @register декораторами, и десериализацией объектов из-за того что под nose в одном случае объект получался из project.app.module, а в другом просто app.module

Понаступав на подобные грабли, я в итоге и написал django-jenkins, который загружает тесты в так же и запускает в том же порядке как и стандартный django test

ИМХО, т.к формат выходных файлов одинаковый, django-jenkins можно и с Teamcity вероятно так же просто использовать.
К статье+ надо добавить в settings.py << TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'.
Если после manage.py test не будет работать.
Я указал:

Кроме того django_nose нужно добавить в INSTALLED_APPS файла settings.py вашего django проекта.

Конечно, можно и в TEST_RUNNER если не хочется в INSTALLED_APPS не принципиально. Добавлю как примечание. Спасибо.
А если я не использую nose, а только webtest, то для передачи данных TeamCity все-равно нужен teamcity-nose?
Only those users with full accounts are able to leave comments. Log in, please.