以TFS的不同方式共享项目文档，您的最佳实践是什么？

Question

我想知道您在管理（和版本控制）不同类型的项目文档方面的最佳做法（例如版本化目标文档，例如：用例，主测试计划，qa计划和非版本控制相关文档，例如MinutesOfMeetings） TFS 2010.

您使用的是

吗？

1. 团队维基或
2. 共享文件或
3. 来源控制

Answer 1

我们对发送给客户的所有文档令牌使用源代码管理。这包括手册/安装指南和类似的。这样他们就可以获得常规的构建标签和我们知道哪个手册对应于哪个版本的软件。

对于内部文档（MoM，设计文档，项目管理等），我们使用Sharepoint＆amp;对于UserStories，我们显然使用内置TFS工作项类型。

Answer 2

我在此加上我的想法：

回答这个问题的最好方法是：没有最佳方法可以做到这一点。这取决于很多因素，这就是为什么每个团队都采用不同的方式。

但是，有一些指导：

• 如果可能，将工件放在可以处理相同类型开发周期的位置。例如，如果您在维基上存储了针对每个软件版本特定的文档，那么您将很快遇到麻烦。版本控制至关重要，因此您必须选择可支持所需版本控制的服务。

• 考虑到受众：您不希望在源代码管理中存储规范word文档。

• 如果有意义的话，不要害怕将信息存储在源代码管理中：您将永远无法获得更好的性能，数据在存储中包含三角形并打包运输到客户端：非常有效。

• 您可以使用工作项来存储您的文档，使用附件，这是一个很好的方式，但肯定不是最容易设置和整个团队购买它。

我推荐的（但它只是个人的）：

• 使用Wiki或Share OneNote一书（OneNote 很棒）作为开发团队内部的文档。 OneNote具有很大的灵活性，可以通过您需要高效的形式主义来构建协作数据。
• SharePoint，用于非开发人员生成或读取的文档。
• 源代码管理，用于存储所有文档/工件的完整版本。当我的发布完成后，我喜欢将所有文档和资源复制到源代码管理的给定文件夹中，这样我就知道我总是能够在需要时恢复它们。 （我对SharePoint或OneNote不太了解。）
• 我曾经使用Work Items开过任何正式的东西，这很棒，但是需要时间和自定义工具来实现我想要的东西。

Answer 3

TFS to SharePoint integration - 如果您的组织有SharePoint，这是存储文档的最佳选择。

否则，请选择更符合以下要求的选项：

• 访问所有项目贡献者的共享文档
• 无需Visual Studio的用户可从网站访问
• 提供版本控制
• 允许权限管理

不推荐使用源代码控制选项，因为非开发人员无法访问它，并且可能会让他们滥用源代码控制（曾尝试下载1GB源代码树，其中大部分是纯垃圾 - 文档存档，日志，数据库转储等等......？）。