Руководства

Шаблоны процесса

• Используйте шаблон процесса MSF Agile в несложных проектах, допускающих неформальный подход.
• Используйте шаблон процесса MSF CMMI в проектах, требующих более формального подхода или соответствия стандартам CMMI.
• По возможности используйте минимальный шаблон процесса.
• Отредактируйте существующий шаблон в соответствии с потребностями вашей команды.

Используйте шаблон процесса MSF Agile в несложных проектах, допускающих неформальный подход

Используя методику разработки через тестирование ( Test-Driven Development, TDD ) или другие гибкие методики, работайте с шаблоном процесса MSF for Agile Software Development (MSF Agile) . Он представляет собой облегченный подход к гибким проектам разработки ПО. Его следует использовать, если вы не слишком нуждаетесь в дополнительных функциях усовершенствования процесса из шаблона MSF CMMI.

Шаблон процесса MSF Agile легко редактировать, изменяя его в соответствии с требованиями вашего процесса.

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

• Дополнительную информацию об управлении проектами вы найдете в лекции 11 этой книги.
• Дополнительную информацию о шаблоне процесса MSF Agile вы найдете в лекции 13 этой книги.
• Дополнительную информацию о настройке шаблона процесса вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server " этой книги.

Используйте шаблон процесса MSF CMMI в проектах, требующих более формального подхода или соответствия стандартам CMMI

При использовании более формального подхода к разработке ПО, направленного на усовершенствование существующего процесса, применяйте шаблон процесса MSF для CMMI Software Development. Его также можно изменить в соответствии с требованиями вашего процесса.

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

• Дополнительную информацию об управлении проектами вы найдете в лекции 11 этой книги.
• Дополнительную информацию о настройке шаблона процесса вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server " этой книги.

По возможности используйте минимальный шаблон процесса

Многим командам не требуется поддержка всех разделов стандартного командного проекта. Например, многие команды довольствуются системой управления исходным кодом и не собираются использовать портал Microsoft Office SharePoint®. В подобных случаях шаблоны командных проектов можно изменять, удаляя ненужные разделы. В шаблоне всегда должны присутствовать разделы Group Permissions и Classifications, от остальных же можно смело избавляться.

Чтобы создать минимальный шаблон, при помощи диспетчера Process Template Manager загрузите шаблон на локальный компьютер, отредактируйте его, удалив ненужные разделы, а затем выгрузите шаблон обратно на сервер.

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

• Дополнительную информацию о шаблонах процесса вы найдете в лекции 13 этой книги.
• Дополнительную информацию о настройке шаблона процесса вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server " этой книги.
• Дополнительную информацию о настройке шаблона процесса вы найдете в статье "Customizing Process Templates" по адресу http://msdn2.micro-soft.com/en-us/library/ms243782(VS.80).aspx.
• Дополнительную информацию об использовании минимального шаблона вы найдете в статье "How to use TFS for source control only" по адресу http://blogs.msdn.com/richardb/archive/2007/05/10/how-to-use-tfs-for-source-control-only.aspx.

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

Проект, над которым вы работаете, может не соответствовать стандартным шаблонам процесса, поставляющимся с Microsoft Visual Studio Team System (VSTS) . Вам может понадобиться другой тип рабочего элемента или иная методология процесса. В таком случае вам следует отредактировать существующий шаблон процесса. Выберите шаблон, максимально близкий к вашим требованиям, и измените его в соответствии с этими требованиями. Как правило, настройке подлежат следующие области шаблона:

• группы и разрешения;
• типы рабочих элементов;
• заметки и политики возврата после правки;
• области и итерации;
• отчеты;
• портал проекта;
• руководство по процессу.

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

• Дополнительную информацию о шаблонах процесса вы найдете в лекции 13 этой книги.
• Дополнительную информацию о настройке шаблона процесса вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server " этой книги.

Группы безопасности и разрешения

• Создавайте группы безопасности для назначения определенного набора разрешений.
• Распределяйте членов команды по соответствующим группам.

Создавайте группы безопасности для назначения определенного набора разрешений

Когда вы создаете новый проект в Team Foundation Server, независимо от выбранного шаблона в нем создается четыре стандартные группы. По умолчанию каждая из этих групп обладает набором определенных разрешений, которые ограничивают полномочия членов этих групп. Четыре стандартные группы таковы:

• Project Administrator - администратор проекта;
• Contributor - участник проекта;
• Reader - читатель;
• Build Services - службы сборки.

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

Руководствуйтесь следующими соображениями:

• не изменяйте разрешения стандартных групп (или сделайте это и во всех остальных проектах);
• используйте группы AD только на уровне сервера;
• для назначения разрешений используйте группы TFS, а не группы AD ;
• никогда и ничего не запрещайте без очень веских причин (запрет чаще всего означает, что используемое вами распределение участников по группам далеко от идеала).

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

• Дополнительную информацию о создании групп безопасности вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server" этой книги.
• Дополнительные сведения о разрешениях TFS вы найдете в статье " Team Foundation Server Permissions " по адресу http://msdn2.microsoft.com/en-us/library/ms252587(VS.80).aspx.

Распределяйте членов команды по соответствующим группам

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

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

• Дополнительную информацию вы найдете в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server " этой книги.

Командные проекты

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

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

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

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

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

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

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

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

Если вы готовы с каждым выпуском начинать все заново, не перенося рабочие элементы и другие папки 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 Team Foundation Server " этой книги.

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

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

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

Ниже приведен пример дерева исходного кода с поддержкой ветвления: Main - контейнер, содержащий все объекты, необходимые для отправки проекта заказчику.

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

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

• Дополнительную информацию о структуре дерева исходного кода вы найдете в лекции 5.