Разделяйте проектные документы в TFS разными способами, каковы ваши лучшие практики?

Мне интересно, какова ваша лучшая практика в отношении управления (и версиями) различных проектных документов (например, для целенаправленных документирования, таких как: примеры использования, мастер-план тестирования, qa-план и не связанные с версиями документы, такие как MinutesOfMeetings, например) в TFS 2010.

Используете ли вы

  • Team Wiki или
  • Общие документы или
  • Контроль источника

?

Ответ 1

Мы используем исходный контроль для всех токенов документации, которые отправляются клиенту. Сюда входят руководства/руководства по установке и тому подобное. Таким образом, они получают регулярные метки сборки, и мы знаем, какое руководство соответствует той версии программного обеспечения.

Для внутренних документов (MoM, проектных документов, управления проектами и т.д.) Мы используем Sharepoint, а для UserStories мы, очевидно, используем сборку - в типах рабочих элементов TFS.

Ответ 2

Я добавляю свои мысли по этому поводу:

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

Однако есть некоторые рекомендации по этому поводу:

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

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

  • Не бойтесь хранить вещи в Source Control, если это имеет смысл: вы никогда не получите лучших результатов, данные дельта упакованы в хранилище и упакованы для транспортировки на клиентскую сторону: ОЧЕНЬ ЭФФЕКТИВНО.

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

Что я рекомендую (но это только личное):

  • Используйте книгу Wiki или Share OneNote (OneNote отлично) для внутренней документации для команды разработчиков. OneNote обладает большой гибкостью для создания совлокальных данных с достаточным количеством формализма, который вам необходим, чтобы быть продуктивным.
  • SharePoint для документов, которые создаются или читаются не разработчиками.
  • Source Control для сохранения полной версии всего вашего документа/артефакта. Когда мой выпуск завершен, мне нравится копировать все документы и активы в заданную папку Source Control, таким образом, я знаю, что всегда могу восстановить их, когда это необходимо. (и я не так уверен в SharePoint или OneNote).
  • Я когда-то делал что-то формальное с Work Items, это было здорово, но нужно время и специальные инструменты для достижения того, что я хотел.

Ответ 3

TFS для интеграции с SharePoint - Если ваша организация имеет SharePoint, это, безусловно, лучший вариант для хранения документов.

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

  • Доступ к общим документам для всех участников проекта
  • Доступный из Интернета для пользователей без Visual Studio
  • Обеспечивает управление версиями
  • Позволяет управлять разрешениями

SharePoint documents and TFS

Опция управления источником менее рекомендуется для того, чтобы быть недоступной для не-разработчиков, и возможность позволить им злоупотреблять исходным элементом управления (когда-либо пытались загрузить исходное дерево 1 ГБ, большая часть которого была чистым нежелательным файлом - архив документации, журналы, базы данных, и т.д.?).