Помнят, что нужно выполнить тесты перед фиксацией

Question

У нас есть достойный набор модульных тестов нашего кода, и те модульные тесты проходят менее чем за 2 минуты. Мы также используем TeamCity для сборки и запуска тестов после каждой проверки. Однако у нас по-прежнему возникают проблемы, когда разработчик «забывает» запускать все тесты перед фиксацией, что приводит к сбою TeamCity, если эта проверка была выполнена в 6 вечера может остаться сломанной ночью.

«Forgets» - общий термин, есть пара других распространенных причин, по которым даже запоминание запуска тестов может привести к сбою TeamCity. Такие как.

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

Как вы справляетесь с этим в своей организации?

Мы планируем ввести «процедуру регистрации» для разработчиков, которая станет автоматическим инструментом, который автоматически выполнит все модульные тесты и затем передаст все «грязные» файлы в вашем рабочем пространстве. Был ли у вас опыт работы с таким процессом? Знаете ли вы о каких-либо инструментах, которые могут облегчить этот процесс? Наша среда для разработчиков - это Python с использованием плагина Eclipse PyDev.

Answer 1

Для mercurial вы можете использовать крючки, которые будут запускать тесты и только позволяют добиваться успеха. Но для этого может потребоваться много времени (но разработчик все равно должен запускать эти тесты).

Или вы можете просто иметь собственный набор сценариев bash, который будет запускать тест и только затем запустить команду commit. Например, для Джанго и СВН совершить это может выглядеть так просто, как это:

./manage.py test && svn commit $@ 

Или есть другой способ: если кто-то совершает код, который не проходит тест, он платит некоторую сумму. Вскоре люди будут помнить, что им не понравится понятие оплаты денег ;-)

Answer 2

Я думаю, что это скорее социальная проблема, чем недостаток автоматизированных систем.

Да, вы можете улучшить системы на месте, но они не будут соответствовать тому, кто думает о последствиях их совершения и проверяет их до того, как они совершают нападки.

Answer 3

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

Answer 4

TeamCity имеет определенную поддержку pretested commit; если ваша команда разработчиков использует поддерживаемую среду IDE, вы можете изучить ее.

В моей компании мы не слишком беспокоимся об этом - наш рисунок выглядит примерно так.

(a) Каждый разработчик имеет собственную конфигурацию проекта в TeamCity, причем корни указывают на собственную песочницу. Им разрешено делать все, что им нравится.

(b) у команды разработчиков есть изолированная песочница, где все изменения доставляются. Проект инкапсулирует конфигурации, которые контролируют эту ветвь в системе управления источником. Dev Leads, чтобы составить правила здесь, но это правило почти всегда «оно должно оставаться зеленым». Я должен был бы посмотреть на точный процент чистых сборок - это не идеальная запись, но ее достаточно высокая, что я никогда не испытывал соблазна настаивать на том, чтобы разработчики были более дисциплинированными в отношении тестов.

(c) фактический доставляемый материал поставляется из основного потока, который должен оставаться зеленым (tm). Dev lead отвечает за предоставление чистого моментального снимка интеграции в основной поток в четко определенном графике. Этот проект является тем, который на самом деле создает установщиков, которые доставляются на тестирование, бит, который входит в условное депонирование и т. Д.

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

Answer 5

Для мерзавец вы можете: http://francoisgaudin.com/2011/02/16/run-django-tests-automatically-before-committing-on-git/

Run Джанго автоматически проверяет, прежде чем совершать на Git

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

Однако очень легко автоматически запускать тесты перед выполнением каждого . В .git/крючки/предварительной фиксации, говоря:

python manage.py 
test exit $? 

затем CHMOD 755 этот файл, и это сделано. Я действительно люблю git :-)

Не забудьте указать свой виртуальный вентилятор перед совершением.

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