Организация исходного кода в 2010 TFS
Мы только что разбудили 2010 TFS и выполнение. Мы будем перемещать наш источник в TFS, но у меня есть вопрос о том, как организовать код.
2010 TFS имеет новое понятие наборов проекта, таким образом, я решил, что различные группы в нашей организации получат свою собственную группу. Моя команда разрабатывает много различных веб-приложений, и у нас есть несколько совместно используемых компонентов. Мы также используем несколько сторонних компонентов (таких как telerik).
Очевидно каждое веб-приложение является своим собственным проектом, но куда я помещаю совместно используемые компоненты? Каждый компонент должен быть в своем собственном проекте с отдельными сборками и объектами работы?
Существует ли лучшая практика или рекомендуемый способ сделать это характерное для 2010 TFS?
3 ответа
Лучше всего, если все, что вам нужно для создания решения, находится в папке Main/Trunk. Мы используем следующий формат:
"Project 1"
"DEV" (Folder)
"Feature 1" (Branch)
"Main" (Root branch)
"Release" (Folder)
"Release 1" (Branch)
"RTM" (Folder)
"Release 1.0" (Branch)
"Release 1.1" (Branch)
Это позволяет держать все ваши ветви на одном уровне, чтобы у вас не возникало сомнений в том, какая из них является ветвью, а какая - папкой.
Это структура вашего командного проекта, но что насчет фактической структуры папок в каждой из ветвей:
Main (Root branch)
"Builds" (Folder that contains all of the MSBuild and Workflows for building)
"Documents" (Folder that contains version specific documents)
"Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex)
"Setup" (Folder contains all of the setup resources)
"[Company].[Namespace].*" (Folders that contains a project)
"Tools" ( Folder for all your nuts and bolts)
"Toolname" (Folder for a specific tool or reference library)
Идея заключается в том, что команда сама решает, использовать ли новую версию внешнего продукта или справочной библиотеки. То, что одна команда может перейти на новую версию NUnit, не означает, что другая команда решит этого не делать, поскольку это займет несколько недель работы.
Всеми средствами имейте центральный проект "Инструменты", который вы всегда обновляете до последней версии, и ваша команда черпает оттуда, но не имейте внешних зависимостей. Это превращает в кошмар автоматические сборки и заставляет ваших разработчиков обновляться, даже если сейчас не самое подходящее время. Кроме того, убедитесь, что вы рассматриваете любую внешнюю зависимость как инструмент, даже если она от другой внутренней команды.
Ссылки: TFS Deployer
У меня два ответа: что мы делаем и что я вам предлагаю.
У нас есть набор веб-приложений, в которых есть МНОГИЕ общие компоненты. Таким образом, хотя это около 50 различных сборок (проекты VS) и 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 доллара ...
Используйте рабочие области, они работают не только с коллекциями групп, но и с большинством методов управления версиями.