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

Question

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

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

Answer 1

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

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

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

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