Как я могу гарантировать, что все модульные тесты пройдут до совершения?

Question

Недавно у нас возникли проблемы, когда разработчики передают код в SVN, который не проходит модульные тесты, не компилируется на всех платформах или даже не компилируется на собственной платформе.Несмотря на то, что все это воспринимается нашим CI-сервером (Cruise Control), и мы создали процессы, чтобы попытаться остановить его, мы действительно хотели бы иметь возможность остановить мошеннические коммиты в первую очередь.

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

http://cf -bill.blogspot.com / 2010/03 / pre-commit-force-unit-tests-without.html

Это решило бы по крайней мере две проблемы (не основанные на Unix), но не отклонило бы фиксацию в случае неудачи.Итак, мои вопросы:

• Есть ли способ сделать ловушку перед фиксацией в TortoiseSVN, чтобы зафиксировать сбой фиксации?
• Есть ли лучший способ сделать то, что я пытаюсьделать вообще?

Answer 1

Нет абсолютно никаких причин, по которым ваш хук перед фиксацией не может запускать юнит-тесты!Все, что нужно сделать перед фиксацией:

• Извлечение кода в рабочий каталог
• Скомпилирование всего
• Запуск всех модульных тестов
• Затем провалите ловушку, если модульные тесты не пройдут.

Это вполне возможно сделать.И, после всего, все в вашем магазине разработки будут ненавидеть ваши кишки.

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

Сколько времени занимает сборка и выполнение модульных тестов?10 минут?Представьте, что вы делаете коммит и сидите там 10 минут в ожидании вашего коммита. Вот почему вам сказали не делать этого.

Ваш сервер непрерывной интеграции - отличное место для проведения модульного тестирования.Я предпочитаю Хадсон или Дженкинс , а не CruiseControl.Их легче настроить, а их веб-страница более удобна для пользователя.Более того, у них есть множество плагинов, которые могут помочь.

Разработчикам не нравится, когда им известно, что они сломали сборку .Представьте, что все в вашей группе получили электронное письмо с сообщением о том, что вы указали неверный код.Разве вы не убедитесь, что ваш код был хорош до того, как вы его зафиксировали?

У Хадсона / Дженкинса есть несколько хороших графиков, которые показывают вам результаты модульного тестирования, поэтому вы можете увидеть на веб-странице, какие тесты пройдены и не пройдены, так что очень ясно, что именно произошло.(Веб-страница CruiseControl труднее анализировать среднему глазу, поэтому эти вещи не так очевидны).

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

Я был удивлен, насколько серьезно к этому относятся разработчики.Как только они поняли, что их игровые результаты КИ были публичными, они стали очень конкурентоспособными.Они будут жаловаться, если сам сервер сборки не получится по какой-то странной причине, и потеряли 10 баллов за плохую сборку .Однако количество неудачных модульных тестов уменьшилось, а количество написанных модульных тестов возросло.

Answer 2

Существует два подхода:

1. Дисциплина
2. Инструменты

По моему опыту, # 1 может вас пока только достичь.

Так что решение, вероятно, инструменты.В вашем случае препятствием является Subversion.Замените его DVCS, как Mercurial или Git.Это позволит каждому разработчику работать над собственной веткой без кошмаров о слиянии Subversion.

Время от времени разработчик будет отмечать функцию или ветку как «завершенную».Это время, чтобы объединить функциональную ветвь с основной ветвью.Вставьте это в «промежуточное» хранилище, которое наблюдает ваш CI-сервер.Сервер CI может затем извлечь последние коммиты, скомпилировать и протестировать их, и только если это пройдет, отправить их в главный репозиторий.

Итак, цикл такой: основной репозиторий -> разработчик -> постановка -> main.

Здесь есть много ответов, которые дают вам детали.Начните здесь: Рабочий процесс Mercurial для ~ 15 разработчиков. Должны ли мы использовать именованные ветви?

[РЕДАКТИРОВАТЬ] Таким образом, вы говорите, что у вас нет времени, чтобы решитьосновные проблемы в вашем процессе разработки ... я позволю вам догадаться, как это звучит для всех ...; -)

В любом случае ... Используйте hg convert, чтобы получить репозиторий Mercurial из вашего дерева Subversion,Если у вас есть стандартные настройки, это не должно занимать много времени (просто потребуется много времени на вашем компьютере, но это происходит автоматически).

Клонируйте это репо, чтобы получить рабочее репо.Процесс работает так:

• Развивайся во втором клоне.Создайте ветки объектов для этого.
• Если вам нужны изменения от кого-либо, преобразуйте в первый клон.Извлеките это из своего второго клона (таким образом, у вас всегда будет «чистая» копия из Subversion на случай, если вы запутаетесь).
• Теперь объедините ветку Subversion (default) и вашу ветку функций.Это должно работать намного лучше, чем с Subversion.
• Когда слияние будет в порядке (все тесты будут выполнены для вас), создайте патч из diff между двумя ветвями.
• Примените патч кместный заказ от Subversion.Следует применять без проблем.Если этого не произойдет, вы можете очистить местный заказ и повторить.Здесь нет шансов потерять работу.
• Зафиксируйте изменения в Subversion, конвертируйте их обратно в репо № 1 и потяните в репо № 2.

Звучит как много работы, нов течение недели вы придумаете сценарий или два для выполнения большей части работы.

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

Когда ваши коллеги жалуются, что кто-то сломал сборку, скажите им, что у вас нет проблем.Когда люди начнут замечать, что ваша производительность намного лучше, несмотря на все скачки, которые вы должны совершить, отметьте, что «было бы намного проще, если бы мы поцарапали SVN».

Answer 3

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