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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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