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

Question

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

Ты используешь

1. Team Wiki или
2. Общие документы или
3. Управления источником

?

Answer 1

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

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

Answer 2

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

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

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

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

• Примите во внимание аудиторию: вы не хотите, например, хранить документ со спецсписками в Source Control.

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

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

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

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

Answer 3

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

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

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

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