Какова оптимальная структура источника VSTF? Есть ли лучшие практики? - PullRequest
0 голосов
/ 19 сентября 2008

Есть ряд других вопросов, связанных с этой темой:

  1. Какая стандартная раскладка кода для приложения php (удалено)
  2. Как структурировать Java-приложение, другими словами: куда мне поместить мои классы?
  3. Рекомендуемая структура каталогов управления исходным кодом?
  4. Структура проектов в управлении версиями

Я не смог найти что-то конкретное для VSTF, в котором есть некоторые возможности, такие как Team Build, интегрированное модульное тестирование и т. Д.

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

Ответы [ 2 ]

1 голос
/ 29 декабря 2008

Несколько мыслей:

  • Очень мало файлов в корне дерева. В большой команде установите разрешения, чтобы никто не мог добавлять новые файлы в корень дерева без какой-либо авторизации.

Рабочая область по умолчанию будет содержать:

  • Инструменты содержит весь исполняемый код, необходимый для создания и запуска модульных тестов, включая пользовательские инструменты и сценарии (возможно, при условии, что Visual Studio и PowerShell уже установлены на компьютере).

  • ReferencedAssemblies содержит вещи, которые вы берете из другого места, в том числе вещи, которые вы покупаете или скачиваете, и вещи, написанные кем-то из команды, но не являющиеся частью этого проекта.

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

  • Документы - элементы, которые не используются как часть сборки, но необходимы для правильного функционирования процесса разработки.

  • Двоичные файлы - биты, которые были отправлены клиентам, включая .PDB и другие артефакты, необходимые для обслуживания. (В небольших проектах я разветвляю исходники для каждого выпуска, но обычно лучше выбрать тег / метку.)


В другом месте (например, $ / personal) есть место, куда каждый человек может обращаться по своему усмотрению ($ / personal / USERNAME). Например, мои побочные проекты идут сюда.

1 голос
/ 19 сентября 2008

Вот тот, который мне нравится:

  • Частный ; все текущие системные результаты
    • Документация ; При свертывании всей документации по решениям, составляющим продукт, выводом будет документация в стиле MSDN от Sandcastle
    • Общее ; Visual Studio SLN, которая содержит все проекты, общие для всех других решений.
    • Инструменты ; Visual Studio SLN, которая содержит все проекты, вывод которых является инструментом. Примером может служить консольное приложение, которое выполняет набор административных задач в более крупной системе
    • Разработчик ; у каждого разработчика есть своя папка, которую они могут использовать для хранения всего, что хотят
      • Конкретный разработчик (1..n) ; он содержит все настройки сборки, сценарии и инструменты, которые этот конкретный разработчик выбирает для хранения в системе управления версиями (они могут делать все, что захотят)
    • Конкретное поставляемое решение (1..n) ; Visual Studio SLN, которая содержит все проекты для конкретного основного результата
      • Common ; папка решения, содержащая проекты Visual Studio, общие для текущего решения
      • UI ; папка решения, содержащая проекты Visual Studio, определяющие взаимодействие с пользователем
      • DataLayer ; папка решения, содержащая проекты Visual Studio, которые определяют уровень доступа к данным
      • Услуги ; папка решения, содержащая проекты Visual Studio, определяющие веб-службы
      • Инструменты ; папка решения, содержащая проекты Visual Studio, определяющие инструменты, специфичные для этого результата (исполняемые утилиты)
      • Тесты ; папка решения, содержащая проекты Visual Studio, содержащие модульные тесты
  • Public ; все внешние зависимости, связанные с системой (например, сторонние библиотеки)
    • Производитель ; зависимости, предоставляемые конкретным поставщиком
  • Сложение ; Visual Studio SLN, которая содержит код, связанный со сборкой проекта, в нашем случае это в основном пользовательские задачи MSBuild и скрипты Powershell
  • Target ; каждая успешная сборка продукта, а также точечные релизы
    • Debug ; все отладочные сборки, которые выводятся из еженедельных сборок и непрерывной интеграции. Разработчики не управляют этим каталогом вручную
      • Номер сборки ; каталог, соответствующий текущему номеру сборки
        • Решение Вывод ; каталог, содержащий все выходные данные сборки для каждого из проектов в данном решении
    • Release ; все релизные сборки, которые выводятся вручную при достижении определенного этапа
      • Номер сборки ; каталог, соответствующий текущему номеру сборки
        • Решение Вывод ; каталог, содержащий все выходные данные сборки для каждого из проектов в данном решении

Примечание: Все решения будут иметь папку «Тесты» и проекты модульных тестов.

...