Стратегия непрерывной интеграции - ссылки проекта против ветвления / слияния

Допустим, у вас есть 7 основных проектов в базе устаревшего кода (корпоративный API). База кода включает около 50 приложений, которые ссылаются на один или несколько основных проектов. Только пара из 50 приложений все еще работает после миграции с vss на tfs, которая была сделана вручную, но не превратилась в грушу. Чтобы приложения снова заработали, многие из них были удалены из корпоративного API и помещены в собственный проект TFS.

Я пытаюсь убедить коллег, что они не должны создавать ветвь основных проектов и помещать копию в отдельные проекты TFS, а только после выпуска объединять дополнения к основному проекту обратно в корпоративный API. в ПРОД. Очевидно, что непрерывная интеграция будет намного сложнее, когда она будет менее частой.

Я пытаюсь убедить коллег, что было бы лучше вынести основные проекты из корпоративного API и поместить их в их собственный проект TFS, а затем сослаться на bin / Debug.

Что лучше: создать ветвь, скопировать ветвь (ветки) для разделения проектов TFS, а затем выполнить их слияние (и увидеть конфликты в конце) или лучше инкапсулировать основные проекты и заставить команду из 20 человек использовать только по одной копии каждого из них. основных проектов?

6
задан Jeremy Thompson 22 November 2011 в 23:51
поделиться