Когда использовать закрытую регистрацию?

Question

Я использую TFS 2010. В настоящее время я использую сборку Gated Check-in только на магистральной (MAIN) ветке.И я использую CI в ветвях DEV и RELEASE.

• Почему бы не использовать сборку Gated Check-in во всех филиалах?
• В каких случаях не следует использовать сборку Gated Check-in в ветвях DEV и RELEASE?
• Лучше ли всегда использовать сборку Gated Check-in для каждой ветви?

Answer 1

В нашей очень большой команде мы также делаем gated в основной ветке и CI в ветках dev / feature (многие из них).

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

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

В обоих случаях разработчики запускают модульные тесты и тестируют код, который они изменяют. CI (влияет на команду) и Gated (занимает время в очереди) не должны заменять тестирование - должно быть более правдоподобное объяснение, более сложное, чем я его не пробовал.

Вся команда находится в ветках feature / dev, использующих CI для большей части цикла, и в более высоких ветвях с большим количеством людей во время стабилизации в конце игры - оба эти последних условия поддерживают случай gated.

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

Answer 2

На самом деле я не знаю причину, по которой не для проведения проверок при каждом внесении изменений. Тем не менее, существует (в целом) предварительное условие для проведения Gated Check-in: ваше общее время сборки не должно превышать нескольких минут, включая любой (модульный) тест, который вы хотели бы выполнить до того, как регистрация будет принята , В противном случае регистрация займет много времени, или, что еще хуже, для разработчика будет отказано. Для команды разработчиков это также немного сложнее, или, по крайней мере, к чему-то, к чему можно привыкнуть.

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

Answer 3

Я предпочитаю Gated Check-In везде, потому что он ограничивает боль при регистрации разработчика, а не делится этой болью со всей командой, когда кто-то (неизбежно) совершает ошибку.

Как упоминалось выше, этоважно, чтобы Gated Check-Ins были быстрыми.Иногда у меня будет Gated Checkin, который выполняет самые важные проверки, а затем сборка CI, которая запускается после успешного выполнения Gated Checkin, которая выполняет более трудоемкие проверки.