Руководства

Создавайте командный проект для каждой версии, если хотите с каждой новой версией начинать все заново

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

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

• Переместить код из одного проекта в другой достаточно просто, а вот перемещать рабочие элементы и прочие ресурсы TFS из одного проекта в другой очень нелегко. Рабочие элементы можно копировать в другой проект только по одному; если вы хотите скопировать набор рабочих элементов, вам потребуется написать собственную утилиту.
• Если количество ваших приложений и выпусков исчисляется сотнями, причем, все они находятся в собственных проектах, вы рискуете снизить производительность TFS и выйти за пределы масштабируемости.
• Выбирая структуру, думайте о дне завтрашнем: реструктуризация командных проектов - трудное занятие.
• Можно легко организовать общий доступ к исходному коду из нескольких командных проектов:
  • ветвлением исходного кода из одного проекта в другой;
  • сопоставлением исходного кода из одного проекта в другой.
• Система Team Foundation Server способна вместить около 500 проектов с использованием Microsoft Solution Framework (MSF) для шаблона процесса 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.

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

Управление общим исходным кодом или двоичными файлами производится в два этапа:

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

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/ aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

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

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

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

• Дополнительную информацию о создании рабочей области вы найдете в статье "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.

Сопоставляйте рабочие области на корневом уровне командного проекта

В новом командном проекте сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей похожее имя, например, C:\TeamProjects. Поскольку сопоставления являются рекурсивными, вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.

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

• Дополнительную информацию о создании рабочей области вы найдете в статье "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.

Используйте уникальный путь к локальной папке на общих компьютерах

Два пользователя одного компьютера не могут использовать одно и то же сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/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.

Сопоставляйте только части дерева исходного кода

Чтобы повысить производительность и сократить использование диска, сопоставляйте только те файлы, которые требуются для проекта разработки. В основном, вам требуются только файлы и проекты, связанные с решением, над которым вы работаете.

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

• Дополнительную информацию о создании рабочей области вы найдете в статье "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

Структурируйте дерево исходного кода с учетом ветвления

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

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

Любое ветвление, проводимое не в папке Main, повлечет за собой копирование структуры папок и файлов в новую ветвь, например:

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

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

• Дополнительную информацию о создании рабочей области вы найдете в статье "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, откуда сможете их извлечь их на следующий день (или передать другому члену команды).

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

Используйте отложенные правки, если в процессе внесения изменений в исходный код вы получили новое более срочное задание (например, исправление ошибки). Для этого вам придется вернуться к стабильной версии кода, но вы не хотите терять свои изменения. Отложите код, чтобы позднее снова извлечь его.

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

• Дополнительную информацию об отложенных правках вы найдете в статье "How to: Shelve and Unshelve Pending Changes" по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx.

Дополнительные ресурсы по управлению исходным кодом

• Дополнительную информацию о системе управления исходным кодом TeamFoundation Server вы найдете в статье "Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181237(VS.80).aspx.