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

Ответ 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
• Обеспечивает управление версиями
• Позволяет управлять разрешениями

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