Как использовать инструмент CI в DCVS с центральным хранилищем? - PullRequest
1 голос
/ 14 февраля 2012

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

Мы настроили TeamCity на получение файла .sln (файл решения) в центральном хранилище для построения проекта.

Но когда некоторые разработчики вносят изменения, центральное хранилище не обновляется автоматически. Затем TeamCity обнаружит изменения в репозитории и получит старую версию в центральном репозитории для сборки. Файлы в центральном хранилище устарели, пока я не обновлю их вручную.

Какой рабочий процесс мне следует выполнить для работы с инструментом CI в DCVS с центральным репозиторием?

Edit:

По комментариям. Это моя конфигурация TeamCity:

enter image description here

enter image description here

enter image description here

Я обнаружил проблему:

Я использовал путь к центральному хранилищу вместо каталога TeamCity Checkout.

Путь к файлу решения: должно быть: src \ BMGChip.sln (относительно каталога извлечения в C: \ TeamCity \ buildAgent \ work )

1 Ответ

2 голосов
/ 14 февраля 2012

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

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

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

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

Если сборка хорошая, вы можете вручную объединить ветку с веткой «master» вашего проекта.CI также настроен для наблюдения за этой веткой и запускает сборку, чтобы убедиться, что слияние прошло успешно.

Существуют различные варианты этой темы - например, разработчики переходят к ветке функций, которая построена,которая затем автоматически объединяется в общую ветку разработки, если сборка прошла успешно.Общая идея такова: любая ветвь общего доступа в вашем центральном репозитории должна иметь настройку CI для ее наблюдения, потому что в определенный момент времени должна быть одна ветка, готовая к выпуску (за исключением любых ручных тестов и т. Д.).

...