Я использую TFS 2010. В настоящее время я использую сборку Gated Check-in только в магистральной (MAIN) ветке. И я использую CI в ветках DEV и RELEASE.
В нашей очень большой команде мы также делаем гейт в основной ветке и CI в ветках dev/feature (многие из них).
Gated предлагает большую защиту для ветки, но с очень большой командой и большой базой кода он может создать резервную копию очереди, если вся команда разработчиков вносит изменения в эту ветку.
CI обеспечивает защиту с немного большим доверием к разработчикам, также зная, что любые проблемы будут быстро обнаружены. Это немного более оптимистично и позволяет команде двигаться намного быстрее, что подходит для ветки разработки.
В обоих случаях разработчики запускают модульные тесты и проверяют код, который они изменяют. CI (влияет на команду) и Gated (потребляет время в очереди) не должны заменять тестирование — должно быть правдоподобное объяснение более сложное, чем я не пробовал.
Вся команда находится в ветках feature/dev, использующих CI в течение большей части цикла, и в ветках более высокого уровня с гораздо большим количеством людей во время стабилизации конечной игры — оба этих последних условия поддерживают случай для gated.
В большой команде нам также необходимо, чтобы сборки CI и скользящие тесты выполнялись параллельно, чтобы быстрее находить проблемы, когда время сборки не является тривиальным, а полные наборы тестов также не являются тривиальными. В этом сценарии люди регистрируются, CI собирает последнюю партию регистрации, запускает сборку, а когда сборка падает, другая машина загружает и запускает наборы тестов.
На самом деле я не знаю причин, по которым не выполнять закрытую регистрацию при каждом вносимом вами изменении. Однако существует (в общем) предварительное условие для выполнения Gated Check-in: общее время сборки не должно превышать нескольких минут, включая любой (модульный) тест, который вы хотели бы выполнить до того, как регистрация будет принята. . В противном случае потребуется много времени, чтобы регистрация была принята, или, что еще хуже, разработчику пришлось бы отклоняться. Для команды разработчиков это также немного сложнее, или, по крайней мере, к этому нужно привыкнуть.
Непрерывная интеграция (на мой взгляд, оптимизированная в виде скользящих сборок) позволяет разработчику проверять свой код, не имея неуверенности, будет ли он принят или нет. Важно то, что разработчику всегда придется как можно скорее сталкиваться с отрицательными конечными результатами проверки. Если вы можете добиться этого, мне это нравится больше, чем закрытая регистрация.
Я предпочитаю закрытую регистрацию везде, потому что она ограничивает боль от регистрации разработчика, а не разделяет эту боль со всей командой, когда кто-то (неизбежно) совершает ошибку.
Как упоминалось выше, важно, чтобы Gated Check-In были быстрыми. Иногда у меня будет закрытая проверка, которая запускает наиболее важные проверки, а затем сборка CI, которая запускается после успешной закрытой проверки, которая выполняет более трудоемкие проверки.
