Недостатки закрытой регистрации в TFS

Я всегда работал с сборкой непрерывной интеграции (CI) в TFS. Однако в моем последнем проекте мы начали использовать запускаемый триггер check-in.

Есть ли недостатки при использовании закрытой регистрации?. Потому что, если это мешает команде проверять сломанный код, какова цель триггера CI?

Ответ 1

Закрытая проверка - это форма построения непрерывной интеграции. В TFS он создает полку, содержащую проверенный код, затем запускает сборку этого кода. Только если этот код будет успешно создан, и все сконфигурированные модульные тесты пройдут, код действительно будет зафиксирован.

Непрерывная интеграция отличается - в CI код выполняется независимо от того, что происходит в результате сборки. Если сборка CI завершилась неудачно из-за того, что код не был зафиксирован, код все еще присутствует в исходном элементе управления, доступном для всех, чтобы захватить.

Теперь для части, основанной на мнении: Gated checkin отлично, если у вас есть большое количество разработчиков с разными уровнями навыков/опыта, поскольку он предотвращает попадание неработающего кода в исходный контроль. Недостатком является то, что он увеличивает время между передаваемым кодом и кодом, доступным для других, и, следовательно, может привести к ситуациям, когда люди сидят вокруг, сжимая большие пальцы, ожидая завершения сборки.

Я рекомендую использовать закрытую регистрацию в качестве остановки. Если у вас есть тонна стробированной сборки входа в систему, она выполняет свою работу и предотвращает получение плохих кодов. Если со временем команда созревает и стробированные сборки check-in выходят из строя редко, то она служит менее целенаправленной и должна быть переключена на непрерывную интеграцию и исправление сбоев в сборе, поскольку они приходят, вместо того, чтобы откладывать каждую фиксацию в случайном случае, возникает проблема.

Ответ 2

Закрытые проверки делают совершение сложнее и медленнее. Обычно это плохо, потому что:

В TDD участники должны иметь возможность выдвигать коммиты при неудачных тестах
Сообщение об ошибках как о неудачных тестах супер полезно
Сотрудничая в ветке WIP (работа в процессе), участники должны иметь возможность вносить грязные изменения, чтобы быстро сделать их доступными для других
При работе над большими изменениями может быть полезно позволить другим участникам просматривать незавершенную работу, прежде чем тратить время на завершение
Многим нравится регулярно совершать незавершенные работы как форму снимка/резервного копирования
совершение незавершенной работы отлично подходит при частом переключении между ветками (сохранение только ограниченной справки, в частности, для новых файлов)
QA не должен быть ограничен во времени, но принятие не должно занимать много времени
В любом случае, проверка качества кода должна происходить в чистой среде, данная локальная среда, скорее всего, не так чиста, как CI-сервер.
Точно так же QA часто следует выполнять с матрицей сред (разные версии компилятора, разные браузеры, разные ОС,...), затраты на настройку лучше вкладывать в центральный CI

Так что сценарии, где gated проверен, в порядке:

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

Ответ 3

Если он настроен неправильно (очень вероятно), вы можете потратить время на разработку няни на сборочной машине, повторяя одну и ту же регистрацию снова и снова, пока система регистрации со стробированием магическим образом не соберет ее правильно. Если вы используете закрытую систему регистрации, я бы порекомендовал настроить специальное рабочее пространство именно для этого, чтобы вы могли зарегистрироваться и приступить к работе над другими вещами, и вам не придется откладывать эти изменения, чтобы вернуться назад и повторно отправить неудавшуюся систему. регистрироваться. PS Выездные проверки ужасны ИМО.... монументальная трата времени и ресурсов.