Вопросы и ответы: система управления исходным кодом и версиями TFS

Управление проектом и рабочей областью

• Как упорядочить командные проекты?
• Как управлять зависимостями между проектами?
• Что такое рабочая область?
• Как изолировать работу разработчика при помощи рабочей области?
• Как эффективно организовать сопоставление рабочей области?
• Когда следует создавать новый проект, а когда - новую ветвь?
• Как управлять исходным кодом, используемым в нескольких проектах?
• Как управлять двоичными файлами, используемыми в нескольких проектах?
• Как организовать дерево исходного кода?

Как упорядочить командные проекты?

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

Выберите одну из следующих стратегий управления командными проектами:

• один проект на приложение;
• один проект на каждый выпуск.

Создание одного проекта на каждое приложение

Если вы намерены переносить из версии в версию не только исходный код, но и рабочие элементы, а также другие объекты TFS, используйте один командный проект на все приложение. Все папки TFS при этом будут автоматически переноситься на следующий выпуск. Когда все будет готово к выпуску новой версии, вы сможете создать для ее изоляции ветвь внутри проекта.

Причины, по которым не следует использовать один проект на каждое приложение:

• В параллельных выпусках будут использоваться одни и те же схемы рабочих элементов, политики возврата после правки и руководства по процессам.
• Будет затруднено составление отчетов. Поскольку отчеты составляются для всего проекта, вам придется использовать фильтрацию по выпуску.
• Если количество разрабатываемых приложений исчисляется сотнями, наличие собственного проекта для каждого из них нанесет ущерб производительности TFS. К тому же, вы рискуете выйти за пределы масштабируемости.
• После нескольких выпусков в проекте набирается огромный "багаж".

Самый простой способ избавиться от него - создать новый проект с переносом в него только нужного кода.

Создание одного проекта на каждый выпуск

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

Причины, по которым не следует использовать один проект на каждый выпуск:

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

Выбирая стратегию, имейте в виду следующее:

• Организовать общий доступ к исходному коду из нескольких командных проектов можно несколькими способами:
  • ветвлением исходного кода из одного проекта в другой;
  • сопоставлением исходного кода из другого проекта в вашей рабочей области.
• Система Team Foundation Server способна вместить около 500 проектов на основе шаблона процесса MSF Agile или до 250 проектов на основе шаблона MSF CMMI. Если вы создаете собственный процесс или настраиваете существующий, помните, на масштабируемость сервера наибольшее влияние оказывает схема рабочих элементов. Чем сложнее схема, там меньше проектов сможет поддерживать сервер.

Дополнительные ресурсы

• Дополнительную информацию об использовании командных проектов вы найдете в статье "When to use Team Projects" по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

Как управлять зависимостями между проектами?

Если вам нужно установить ссылку на внешний файл сборки, который был создан вне вашего решения Visual Studio, например, на библиотеку DLL стороннего производителя, у вас есть три варианта действий:

• Вы можете хранить внешний файл сборки как двоичный ресурс в составе вашего проекта. Этот вариант подходит для случаев, когда вы хотите сохранить зависимость для других проектов, которым может понадобиться ссылка на нее, или когда ваш проект - единственный, которому нужна эта зависимость.
• Вы можете сослаться на сборку, находящуюся на сервере сборок, при помощи буквы виртуального диска или UNC -пути.
• Вы можете хранить набор внешних файлов сборок в папке общего командного проекта. Этот способ удобен при наличии нескольких проектов, ссылающихся на общую зависимость, когда ваш проект не является ее очевидным собственником.
  • Если в случае изменения двоичного файла вы желаете получать обновление немедленно, создайте сопоставление рабочей области этого командного проекта с вашим локальным компьютером. Внутри локальной структуры создайте файловую ссылку на сборку.
  • Если вы хотите управлять расписанием сборки данной зависимости, создайте ветвь из общего проекта в ваш проект, чтобы переносить изменения к себе в любое удобное для вас время.

В целом, следует избегать зависимостей, переходящих из проекта в проект. Старайтесь объединять все связанные и зависимые решения и проекты в одном командном проекте. Это сократит трудозатраты на разработку сценария сборки. Если у вас есть зависимость, для ее определения используйте ссылки на проект. Избегайте файловых ссылок, ибо ими намного труднее управлять.

Примечание Ссылки между различными проектами поддерживаются внутри решения. Имейте в виду, что файл проекта ( csproj, vjsproj, vcproj, vbproj и т. д.) может включаться в несколько решений ( sln -файлов). Иными словами, один проект может использоваться несколькими решениями.

Дополнительные ресурсы

• Дополнительную информацию о ссылках на проект вы найдете в статье "Project References" по адресу http://msdn2.microsoft.com/en-us/library/ ez524kew(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx.
• Дополнительную информацию о рабочих областях вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181383(VS.80).aspx.

Что такое рабочая область?

Рабочей областью ( workspace ) называется клиентская копия файлов и папок с сервера управления версиями TFS. Локальные ожидающие изменения изолируются внутри рабочей области, пока вы не вернете их на сервер в виде единого блока (набора изменений). Одна рабочая область может содержать ссылки на несколько командных проектов. Для изоляции файлов или версий вы вольны использовать несколько рабочих областей.

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

Дополнительные ресурсы

• Дополнительную информацию о рабочих областях вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181383(VS.80).aspx.

Как изолировать работу разработчика при помощи рабочей области?

Вы, как разработчик, можете создать две рабочих области: в одной разместить файлы и папки, над которыми работает вся команда, а в другой - файлы и папки, которые вы хотите изолировать. Изоляция файлов может понадобиться, чтобы какое-то время работать над ними параллельно с основной разработкой. В частности, этот способ может использоваться для работы над рискованными ожидающими изменениями или при рецензировании кода.

Дополнительные ресурсы

• Дополнительную информацию о рабочих областях вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181383(VS.80).aspx.

Как эффективно организовать сопоставление рабочей области?

Сопоставление рабочей области - это средство отображения находящихся на сервере файлов и папок на ваш локальный диск.

Создавая сопоставления рабочей области, используйте следующие рекомендации:

• Сопоставляйте рабочие области на корневом уровне командного проекта В новых командных проектах сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей то же имя, например, C:\TeamProjects. Вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.
• Используйте уникальный путь к локальной папке на совместно используемых компьютерах Два пользователя одного и того же компьютера не могут использовать одно сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/MyTeamProject ) с одной и той же папкой на локальном компьютере. Создавайте сопоставления в папке Мои документы (хотя это удлиняет путь) или разработайте соглашение об именах для папок на локальном компьютере (например, C:\ TeamProjects\User1, C:\TeampProjects\User2 и т. д.).
• Подумайте, нужно ли вам все дерево Чтобы увеличить производительность и сократить занимаемый объем диска, сопоставляйте только те файлы, которые требуются для проекта разработки. Как правило, вам требуются файлы и проекты, связанные с решением, над которым вы работаете.
• Не используйте сопоставление рабочей области для поддержки зависимостей между различными проектами Как правило, следует избегать зависимостей, пересекающих командные проекты. Старайтесь объединить все связанные и зависимые решения и проекты в одном командном проекте. Это позволит реже прибегать к настройке сборочного сценария. Если у вас есть зависимость, для ее определения используйте ссылки на проект или перенесите зависимость из общего проекта в свой проект. Следует избегать файловых ссылок, потому что ими сложнее управлять. Исключение составляют случаи, когда параллельно ведется разработка зависимого проекта, и вам нужно получать изменения в реальном времени. В этом случае вы можете воспользоваться сопоставлением рабочей области. Если зависимый код приводит к появлению большого количества серьезных ошибок, используйте ветвление.

Дополнительные ресурсы

• Дополнительную информацию о создании рабочей области вы найдете в статье "How to: Create a Workspace" по адресу http://msdn2.microsoft.com/ en-us/library/ms181384(VS.80).aspx.
• Дополнительную информацию об изменении рабочей области вы найдете в статье "How to: Edit a Workspace" по адресу http://msdn2.microsoft. com/en-us/library/ms245466(VS.80).aspx.

Когда следует создавать новый проект, а когда - новую ветвь?

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

Создавайте новый командный проект, если намерены использовать новые ресурсы TFS (рабочие элементы, руководство процесса и отчеты). Также следует создавать новый командный проект, если вы собираетесь перенести код, не перенося другие ресурсы TFS.

Дополнительные ресурсы

• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о добавлении нового проекта вы найдете в статье "How to: Add a Project or Solution to Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181373(VS.80).aspx.

Как управлять исходным кодом, используемым в нескольких проектах?

Управление общим исходным кодом включает в себя принятие двух решений:

1. Где хранить исходный код?
2. Как ваша команда будет получать доступ к нему? Возможны следующие варианты хранения исходного кода:
   • Если исходный код явно принадлежит той или иной команде, храните его в проекте этой команды.
   • Если у совместно используемого исходного кода нет конкретного владельца, создайте командный проект специально для его хранения. Если вы хотите использовать исходный код в другом проекте, выберите один из следующих вариантов:
     • Если вам нужно поддерживать постоянную синхронизацию с совместно используемым кодом, создайте сопоставление между местом его хранения и локальной рабочей областью на клиентских компьютерах.
     • Если синхронизация требуется вам лишь периодически, выполните ветвление из общего расположения в целевой проект. Каждый раз при слиянии из общего расположения в целевой проект вы будете копировать новую версию исходного кода.

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

• Main - контейнер всех ресурсов, необходимых для выпуска ПО.
  • Source - контейнер для всего, что нужно для сборки.
    • Code - контейнер для исходного кода.
    • Shared Code - контейнер для исходного кода, заимствованного из других проектов.
    • Unit Tests - контейнер для модульных тестов.
    • Lib - контейнер для двоичных зависимостей.
  • Docs - контейнер для документации, поставляющейся с продуктом.
  • Installer - контейнер для исходного кода и двоичных файлов программы установки.
  • Builds - контейнер для сценариев сборки.
  • Tests - контейнер, содержащий результаты тестирования.

Дополнительные ресурсы

• Дополнительную информацию о ссылках на проект вы найдете в статье "Project References" по адресу http://msdn2.microsoft.com/en-us/library/ ez524kew(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о рабочих областях вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181383(VS.80).aspx.