Это действительно зависит от зрелости вашего общего кода.Я бы сказал, что вы можете придерживаться трех подходов, каждый из которых имеет свои плюсы и минусы:
Вариант 1: напрямую ссылаться на них из собственного командного проекта
Team Project Application 1
--> Development
--> ...
--> MAIN
--> Sources
--> Application 1
--> Application1.sln
Team Project Application 2
--> Development
--> ...
--> MAIN
--> Sources
--> Application 2
--> Application1.sln
Team Project CoreProject 1
--> Development
--> ...
--> MAIN
--> Sources
--> CoreProject1.csproj
С этимподход, вы можете установить в своих сборках CI, чтобы все Приложения начинали собираться после того, как вы зарегистрировались в CoreProject.
Вы обязаны иметь групповые проекты, локально сопоставленные с соглашением (иначе компиляция нарушится)
Это хороший подход, если вы постоянно меняете CoreProject и нуждаетесь в том, чтобы эти изменения быстро отражались на всех затронутых приложениях.
Это также означает, что вы можете допустить нестабильность в определенном приложении, если произойдет серьезное изменение вCoreProject.
Вариант 2: косвенная ссылка на них через разветвление
Team Project Application 1
--> Development
--> ...
--> MAIN
--> SharedSources
--> CoreProject1_branch
--> CoreProject1.csproj
--> Sources
--> Application 1
---> Application1.sln
Team Project Application 2
--> Development
--> ...
--> MAIN
--> SharedSources
--> CoreProject1_branch
--> CoreProject1.csproj
--> Sources
--> Application 2
---> Application1.sln
Team Project CoreProject 1
--> Development
--> ...
--> MAIN
--> Sources
--> CoreProject1.csproj
При таком подходе каждый раз, когда вы проверяете изменения в CoreProject1, вам необходимо организоватьобъединить с каждым задействованным приложением.Это требует определенных усилий, но дает вам время для стабилизации CoreProject на его собственной площадке и последующего слияния его с вашими приложениями.
Этот подход подразумевает, что у вас также есть определение сборки для каждого CoreProject.
В общем, этохороший способ продолжить, если вы цените стабильность CoreProject и не можете позволить себе «загрязнять» ваши Приложения, если изменения вызовут проблемы.Это подход, к которому мы пошли.
Вариант 3: сделать ссылку на файл в каждом приложении
Team Project Application 1
--> Development
--> ...
--> MAIN
--> SharedBinaries
--> CoreProject1_branch
--> CoreProject1.dll
--> Sources
--> Application 1
---> Application1.sln
Team Project Application 2
--> Development
--> ...
--> MAIN
--> SharedBinaries
--> CoreProject1_branch
--> CoreProject1.dll
--> Sources
--> Application 2
---> Application1.sln
Team Project CoreProject 1
--> Development
--> ...
--> MAIN
--> Sources
--> CoreProject1.csproj
При таком подходе вам необходимо проверить двоичный выводсборки CoreApplication в каждое приложение.
Это рекомендуется только в том случае, если вы уверены, что CoreApplication стабильно и вам не нужно регулярно его отлаживать.
По существу, вариант 2 и вариант 3похожи, разделены известными дебатами "проект против ссылки на файл".См. здесь для SO-ресурса, еще много можно найти с помощью поиска.
Если ваши основные проекты связаны с постоянными изменениями и / или имеют низкий охват модульными тестами, вам следует выбрать вариант 2 (или 3).
Если вы уверены в их качестве, выберите вариант 1это хороший выбор, так как он значительно повысит вашу общую производительность.
Без каких-либо знаний о ваших продуктах и их качестве, просто на основе довольно большого количества предоставленных вами данных (20 человек, 50 решений, 7 основных проектов)Я бы выбрал вариант 2 / 3.
Еще один важный совет: чаще всего бывает, что совместно используемый проект не имеет средств для раздельного тестирования.Если это так, и в базовых проектах нет собственных модульных тестов, нет специального плана тестирования и т. Д., То нет смысла делать что-либо еще, кроме варианта 1.
Дополнительным большим ресурсом по этому вопросу является работа. рейнджерами ALM.