TFS - сколько вложений на структуре диска

Question

Мы только что установили TFS и готовы к работе. Я пытаюсь определиться со структурой диска. Предположим, у меня есть два проекта BizTalk, которые называются Common и BookTransfer (на самом деле у меня есть 7). [В этом клиенте мы приняли стиль, состоящий в том, чтобы иметь схемы, схемы и карты в одном проекте под названием BizTalk.Artifacts]. Папка с именем "компоненты" является кодом C#. Мы используем инструмент CodePlex, называемый средой развертывания BizTalk, который в некоторой степени определяет часть структуры.

Я пытаюсь решить, сколько вложений мы должны сделать в каталогах дисков (EC - это имя приложения, а приложения Common/BookTransfer или BizTalk выделены для упрощения развертывания / отмены развертывания).

Предложение № 1:

-EC
  - Main
     - Source
        - Common
           - Company.EC.Common.Biztalk.Artifacts [folder]
           - Company.EC.Common.BizTalk.Components [folder]
           - Company.EC.Common.Biztalk.Deployment  [folder]
           - Company.EC.BookTransfer.BizTalk.sln
        - BookTransfer
           - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
           - Company.EC.BookTransfer.BizTalk.Components [folder]
           - Company.EC.BookTransfer.BizTalk.Components.UnitTest [folder]
           - Company.EC.BookTransfer.BizTalk.Deployment [folder]
           - Company.EC.BookTransfer.BizTalk.sln

Предложение № 2 - более плоский подход

-EC
  - Main
     - Source
         - Company.EC.Common.BizTalk.sln
         - Company.EC.BookTransfer.BizTalk.sln
         - Company.EC.Common.Biztalk.Artifacts [folder]
         - Company.EC.Common.BizTalk.Components [folder]
         - Company.EC.Common.Biztalk.Deployment [folder]
         - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
         - Company.EC.BookTransfer.BizTalk.Components [folder]
         - Company.EC.BookTransfer.BizTalk.Components.UnitTest  [folder]
         - Company.EC.BookTransfer.BizTalk.Deployment [folder]

Текущая структура (возможно, слишком много вложенных папок)

- Main
   - Source
     - Company
        - EC
          - Common
            - BizTalk
                -Company.EC.Common.Biztalk.Artifacts [folder]
                -Company.EC.Common.BizTalk.Components [folder]
                -Company.EC.Common.Biztalk.Deployment  [folder]
                -Company.EC.BookTransfer.BizTalk.sln
         - BookTransfer
           - BizTalk
              - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
              - Company.EC.BookTransfer.BizTalk.Components [folder]
              - Company.EC.BookTransfer.BizTalk.Components.UnitTest [folder]
              - Company.EC.BookTransfer.BizTalk.Deployment [folder]
              - Company.EC.BookTransfer.BizTalk.sln

"Основное" - в случае, если мы разветвляемся, у нас будут другие ветви с идентичной структурой.

Answer 1

Умеренно плоский лучше. Глядя на ваши примеры, я должен предупредить вас, чтобы вы были осторожны с общей длиной пути / имени файла. Вы можете очень быстро набрать максимальную длину пути в 260 символов, особенно если вы строите на отдельном сервере сборки, так как вам также необходимо учитывать длину этого пути.

Наш подход был:

Team Project
   - Main
     - LocalBin
     - Src
        - Subject Area
          - SubjectArea.sln
          - src
             - subjectarea.csproj

Мы использовали LocalBin в качестве нашей цели для сборок, поскольку это значительно упростило создание наших проектов пакетов WIX, поскольку мы находимся в корпоративной среде, и мы создаем крупномасштабные MSI для наших развертываний (например, один из наших пакетов имеет 400+ DLL).

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