Какова оптимальная структура источника VSTF? Есть ли лучшие практики?

Question

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

1. Whats a good standard code layout for a php application (удален)
2. How to structure a java application, in other words: where do I put my classes?
3. Recommended Source Control Directory Structure?
4. Structure of Projects in Version Control

Я не мог найти какой-либо конкретной к VSTF, который имеет некоторые возможности, такие как Team Build, интеграция и т. д. Мне интересно, могут ли эти возможности привести к немного другой рекомендации по компоновке исходного кода.

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

• Источник - весь исходный код, включая файлы проекта.

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

• Бинарные - биты, которые были отправлены клиентов, в том числе .PDBs и других артефактов, необходимых для обслуживания. (На небольших проектах я раскошелиться источники для каждого выпуска, но обычно тег/метка является лучшим выбором.)

---

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