У меня есть два ответа: что мы делаем и что я предлагаю для вас.
Для нас у нас есть набор веб-приложений, каждый из которых имеет МНОГИЕ общие компоненты.Таким образом, хотя это около 50 различных сборок (VS Projects) и 5-10 решений (в зависимости от того, как вы на это смотрите), все они очень сильно перекрываются, что означает, что мы хотим использовать TFS для каждого разработчика, а нечем ветвление и объединение этих перекрывающихся ресурсов.Таким образом, мы фактически храним все это в одном проекте TFS.Вот как у нас есть наши настройки (имена изменены, чтобы иметь смысл для вас):
"Official Projects" (Collection)
"Production Applications" (Project)
"Technology Proof of Concepts" (Project)
"Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
"TFS Configuration" (Project)
"Playground" (Collection)
"John Doe" (Project)
"Jane Doe" (Project)
"Security Team" (Project)
"Production Test" (Project)
В нашей настройке у нас есть место для официальной балансовой единицы.Кроме того, у нас есть область, где люди могут бездельничать, не боясь что-либо испортить, и при этом могут воспользоваться различными преимуществами, связанными с TFS.читая между строк правильно, я бы предложил что-то другое.Мои предположения:
- Каждый проект, за исключением нескольких общих сборок (я думаю, что журналы, безопасность и другие сборки утилит, которые являются общими для всей компании), являются несвязанными проектами.
- Общие / общие сборки не меняются регулярно, поэтому вы можете использовать ссылки DLL, а не ссылки на проекты, где вы всегда используете последнюю актуальную версию кода.
- (Предположение на основе TFS, поскольку я все еще учусь) Вы можете выполнять ветвление между проектами из одной и той же коллекции, но не можете выполнять ветвления между коллекциями.
- Кроме вышеупомянутых общих сборок, никакой другой код не передается группам..
Итак, с этими допущениями я хотел бы пойти примерно так:
"Common Resources" (Collection)
"Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
"Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
"Version 2" (Project)
"Version 3" (Project"
etc.
"Team 1" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Project 4"
"Project 5"
"Team 2" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Team 3" (Collection)
"Project 1"
"Project 2"
etc.
Делая это таким образом, вы обращаетесь к общим сборкам через ссылки на DLL.Вы, как команда или разработчик конкретного проекта, решаете, когда вы начнете использовать более новую версию общей сборки.Чтобы сделать это, вы просто получите последнюю версию ветки этой версии, а затем добавите ссылку на нее.Если мое предположение № 3 неверно, то, надеюсь, вы можете сделать что-то лучше, чем это.В противном случае у каждого проекта есть свое собственное пространство (которое может содержать более одного решения / проекта VS, что является хорошей идеей), и у вашей команды есть своя собственная коллекция, чтобы оставаться в стороне от других команд.
Просто мои 0,02 долларастоит ...