Какие программы контроля версий могут обеспечить выполнение и прохождение тестов до интеграции изменений?

Question

В моей работе в настоящее время мы используем Aegis контроль версий / SCM. То, как мы его настроили, у нас есть куча тестов, и это заставляет следовать следующим вещам, прежде чем изменение может быть интегрировано:

• Должен быть выполнен полный набор тестов.
• Все тесты должны быть пройдены.

При разработке через тестирование (TDD) эти требования кажутся разумными. Но я не слышал о том, как вы можете сделать это с любыми другими системами контроля версий. (В настоящее время мы не планируем переключаться, но я хотел бы знать, как это сделать в будущем без использования Aegis.)

Я был бы заинтересован в любой VCS (распределенной или нет), которая может сделать это, меня также интересуют любые плагины / расширения для существующих VCS, которые позволяют это. Предпочтительно программное обеспечение с открытым исходным кодом.

ETA: ОК, кажется, что обычно нужно иметь программное обеспечение для непрерывной интеграции VCS +, и выполнение тестов автоматизируется как часть сборки, а не как отдельный шаг. Если я правильно понимаю, что позволяет фиксировать код, который не проходит тесты, просто вы получаете уведомление об этом - это правильно? Есть ли что-нибудь, что могло бы помешать вам вообще интегрировать / зафиксировать это?

Answer 1

IMO, вам гораздо лучше использовать систему непрерывной интеграции, такую ​​как CruiseControl или Hudson , если вы хотите добиться того, чтобы ваши тесты прошли, и сделать сборку, а не проверку. в зависимости от результатов испытаний. Инструменты просты в настройке, и вы получаете преимущества встроенного уведомления о результатах (через электронную почту, RSS или плагины браузера) и отчеты о результатах тестирования через веб-страницу.

Что касается обновления вопроса, вы правы - VCS + CI позволяет вам фиксировать код, который не проходит тесты; с большинством настроек CI вы просто не получите окончательную сборку вашего продукта, если не пройдете все тесты. Если вы действительно хотите, чтобы кто-то даже не совершал коммиты, пока не пройдут все тесты, вам придется использовать хуки в VCS, как предлагали другие. Однако мне кажется, что с этим трудно иметь дело - либо разработчикам придется запускать все тесты каждый раз, когда они делают проверку, включая тесты, которые не имеют отношения к проверке, которую они выполняют, или вам придется создайте несколько очень детализированных хуков VCS, которые запускают только те тесты, которые имеют отношение к данной регистрации. По моему опыту, гораздо эффективнее полагаться на то, что разработчики будут запускать соответствующие тесты локально, а система CI обнаружит случайные ошибки.

Answer 2

Subversion и git оба поддерживают это с помощью хуков предварительной фиксации.

Visual Studio Team System изначально поддерживает это с помощью политик регистрации .

Я считаю, что Rational ClearCase также поддерживает его, хотя я никогда не видел этого, поэтому не могу сказать наверняка.

Answer 3

С помощью subversion и git вы можете добавить хуки предварительной фиксации, чтобы сделать это.

Похоже, вам нужно взглянуть на непрерывную интеграцию (или вариант).

Думаю, у Git также есть патч для применения патча.

Answer 4

Мы используем git и buildbot , чтобы сделать нечто подобное, хотя и не совсем то же самое. Мы даем каждому разработчику свой собственный репозиторий Git, и у нас есть набор buildbot для сборки в любое время, когда один из этих репозиториев отправляется. Тогда есть кто-то, кто действует как интегратор, который может проверить состояние buildbot, просмотреть изменения и объединить их изменения или сказать им, чтобы исправить что-то в зависимости от ситуации.

Существует множество вариантов этого рабочего процесса, которые вы можете использовать в Git. Если вы не хотите, чтобы кто-то был интегратором вручную, вы, возможно, могли бы настроить buildbot для запуска сценария при успешном выполнении, который автоматически объединит изменения этого человека в главный репозиторий (хотя это должно было бы иметь дело со случаями, когда автоматическое слияние не сработало, и ему пришлось бы также проверить результаты слияния, поскольку даже код, который сливается корректно, иногда может создавать другие проблемы).

Answer 5

Вы также можете использовать ловушки предварительной фиксации в Perforce. И, если вы магазин .NET, Visual Studio может быть настроен на обязательную проверку.

Answer 6

Я считаю, что программное обеспечение для непрерывной интеграции, такое как team city, позволяет выполнять сборку и тестирование перед фиксацией. Я не знаю ни одного vcs, который бы предоставлял его напрямую ... могут быть такие, которые вы используете, но я не знаком с ними.

Answer 7

Большинство реализаций CI имеют механизм отклонения регистрации, которая не соответствует всем критериям (прежде всего, проходит все тесты). Их называют разными именами. VCS должен делать то, что умеет лучше всего ... исходный код версии.

• TeamCity - Предварительно протестированный коммит
• TFS - Закрытые проверки

Answer 8

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

Вы можете найти больше информации о стратегиях интеграции здесь , а также комментарии о Марке Шаттлворте о контроле версий здесь .

Answer 9

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