Team Foundation Server - руководство программиста

В дополнение к моей предыдущей теме на

Как использовать SVN, Branch? Тег? Ствол?

Я хотел бы подробно рассказать о том, как программист должен/мог использовать TFS.

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

Итак, это мои интересные моменты, о которых я хотел бы узнать больше:

  • Как бы вы структурировали Рабочую область/Проект TFS для поддержки множества разных клиентов/проектов и, возможно, разных проектов для каждого клиента?
  • Разделение структуры папок на вышеуказанный проект на разные части, такие как Code, Documents → Architecture, Requirements и другие, что еще может быть и что будет хорошей широко используемой структурой папок?
  • Удобный просмотр репозитория; Снова структура папок здесь важна, однако этот момент больше нацелен на разных Исследователей для репозитория, а не только на встроенный Team Foundation Explorer.

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

ОТВЕТЫ

Ответ 1

Как уже упоминалось, руководство по шаблонам и практике является отличным руководством для всего использования TFS.

http://www.codeplex.com/TFSGuide

Однако, если вам захочется сосредоточиться на стратегиях ветвления, вы можете также проверить направляющие разветвления (особенно вторую версию), которые собирают VSTS Rangers.

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

http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/threads

Ответ 2

Вы упомянули об этом руководстве: http://www.codeplex.com/TFSGuide

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

Используемая нами структура такова:

TeamProject1
    Main
        Source
            ClassLibrary1
            ClassLibrary2
            CommonCodeLibrary
            TeamProject1Web
    Releases
        Release1
            Source
                ClassLibrary1
                ClassLibrary2
                CommonCodeLibrary
                TeamProject1Web
        Release2
            Source
                ClassLibrary1
                ClassLibrary2
                CommonCodeLibrary
                TeamProject1Web
TeamProject2
    Main
        Source
            ClassLibrary1
            CommonCodeLibrary
            TeamProject2Web
    Releases
        Release1
            Source
                ClassLibrary1
                CommonCodeLibrary
                TeamProject2Web
        Release2
            Source
                ClassLibrary1
                CommonCodeLibrary
                TeamProject2Web
SharedTeamProject //this would represent a set of code that used in other team projects
    Main
        Source
            CommonCodeLibrary
    Releases
        Release1
            Source
                CommonCodeLibrary
        Release2
            Source
                CommonCodeLibrary

В принципе, мы разворачиваем проект Main\Source в ветки Release\Releasex, когда нужно время для выпуска.

Для кода, разделяемого несколькими проектами, мы создаем отдельный командный проект для этого кода, а затем мы встраиваем его в отдельные командные проекты. В приведенном ниже примере SharedTeamProject представляет собой общий код. Например, мы разделили CommonCodeLibrary на обучение основным папкам \Source для отдельных командных проектов.

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

Я думаю, что главное - придумать схему, согласно которой ваша команда соглашается (в основном), понимает и готова следовать. Удостоверьтесь, что схема документально подтверждена и что она соблюдалась. Согласованность в структуре является одним из ключей к успешной системе управления версиями.

Ответ 3

Вот что я думаю о ваших точках:

  • Прежде всего, есть уровень Team Project. Лучше всего следовать рекомендациям Microsoft: физические команды имеют отдельные командные проекты. Для изменений, связанных с клиентом, я делаю дополнительные ветки из ствола. Это позволяет объединить все исправления ошибок и независимые от клиента изменения в ветвях клиентов без лишних хлопот.
  • Не помещайте документы в исходный элемент управления, поместите их в папку "Документы", которые можно найти в Team Explorer. Для всей документации, которую я бы сказал, просмотрите Sharepoint.
  • Попробуйте сопоставить структуру вашей папки с иерархией пространства имен. Это делает вещи чрезвычайно удобными для просмотра.

Помните, что настройка TFS действительно зависит от размера команд, количества команд и размера кодовой базы.