Сборка и юнит тест на пуш?

Question

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

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

Кто-нибудь делал что-нибудь подобное или есть какие-либо комментарии?

Answer 1

Для меня это анти-паттерн. Mercurial, система контроля версий, предназначена для версии ваших источников. Это не система сборки, система непрерывной интеграции, пакетное тестирование или что-то в этом роде. Вы должны делегировать подобные вещи соответствующему инструменту, а ловушка типа pre-commit не подходит. Я бы использовал пакет непрерывной интеграции с открытым исходным кодом Jenkins (http://jenkins -ci.org /) и делал build / test / etc после commit / push. Вы можете настроить Jenkins на множество вещей, основанных на результатах сборки.

Answer 2

Книга Mercurial охватывает этот случай http://hgbook.red -bean.com / read / processing-repository-events-with-hooks.html . но вот несколько заметок:

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

Вам лучше, если ваша система непрерывной интеграции наблюдает за центральным репо, запускает сборку всякий раз, когда появляются новые наборы изменений, и подает сигнал тревоги, когда тесты не пройдены. Люди, которые потянулись до того, как прозвучал сигнал тревоги, легко смогут вытащить исправления из смущенного кодера, который сломал сборку. http://www.youbrokethebuild.com/

Answer 3

Это называется закрытой регистрацией или предварительным подтверждением.Некоторые системы CI допускают это, а некоторые - нет.

Вот статья в блоге о том, как TFS делает такие вещи: http://spandothers.wordpress.com/2010/06/08/tfs-2010-gated-check-ins/

ИМХО, это функция meh.Зарегистрируйтесь, сломайте сборку, исправьте ее и двигайтесь дальше.Разорвать сборку не должно быть так уж сложно.

Answer 4

Я знаю это по именам «закрытая регистрация» или «поэтапная регистрация».

Крупные компании, такие как Microsoft (где я раньше работал) и Sun (не могли найти ссылку), предпочитают дополнительную уверенность и производительность систем тестирования («сборка не может быть разбита по замыслу») над производительностью разработчиков. («регистрация занимает 1-2 часа»). Люди, которые работали только над небольшими компаниями или небольшими проектами, обычно сходят с ума от этой идеи, но вы должны сами заняться математикой.

Я видел два способа реализовать это самостоятельно (и не знаю ни одного продукта, который это делает):
* На стороне клиента: замените общий инструмент регистрации (CL, GUI) на свой собственный, который зафиксирует изменения во временной ветви (или просто поместит файл diff в какое-то временное место), а затем запустит выполнение некоторого удаленного сборочный агент, который примет изменения и выполнит быструю сборку и базовое тестирование (или тесты smote). Когда все хорошо, изменения действительно проверены.
* На стороне сервера: настройте управление версиями таким образом, чтобы люди получали код из «стабильного» местоположения, но передавали изменения в «рабочее» местоположение (по одному на разработчика, команду и т. Д.). Затем включите CI-сервер при регистрации на рабочем месте и автоматически перенесите их в «стабильную ветвь» в случае успеха или верните их в случае сбоя.

Я не защищаю этот подход, просто посмотрите, что соответствует вашим потребностям.