每个项目或公司的 FitNesse Wiki？
对于拥有许多开发项目的公司，您应该创建多个 FitNesse wiki（每个项目/产品一个）还是将它们全部包含在一个包含所有内容的大型 wiki 中？
大型 wiki 的优点是能够轻松链接到公司的其他产品，并且它是所有 FitNesse 测试的一站式位置。
或者，多个 wiki 的优点是将测试的自动化划分到多个服务器变得更容易，将 wiki 与项目分支/标签一起分支变得更容易。
我对这两种可能性的优点和缺点或深思熟虑的替代方案感兴趣（例如，不是“只是以某种方式将维基根结合在一起”）。
For a company with many development projects, should you create multiple FitNesse wikis (one for each project/product) or contain them all within a large wiki for everything?
Advantages of one large wiki is the ability to easily link to other products in the company and that it is a one-stop location for all the FitNesse tests.
Alternatively, the advantages of multiple wikis is it becomes easier to divide automation of the tests to multiple servers, it becomes easier to branch the wiki along with a project branch / tag.
I'm interested in the advantages and disadvantages of these two possibilities or a well thought out alternative (e.g. not "just combine the wiki roots together somehow").
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来这一切都归结为管理问题：
有多少台服务器可用以及由谁管理它们？
一台中央服务器意味着一台能够承受负载的服务器，无论是在请求方面（所有项目的所有开发人员都可以相当定期地进行许多查询），还是在“服务器上”FitNesse 相关计算方面。
另一个标准是可见性。 您的开发项目是否需要查看彼此的 FitNesse 指标？ 出于“政治”原因，其中一些指标可能并不总是欢迎其他项目随时看到！ 一些项目经理可能希望让他们保守秘密并控制他们的官方沟通。
事实上，正是出于后一个原因，我们的 FitNesses wiki 由每个团队管理，更多地作为一个内部工具。 我们有另一个全球维基（基于 Confluance），用于管理每个项目的全球文档。 这些常见的 wiki 可能会提取一些内部 FitNesse wiki 数据。
It seems it all boils down to an administration problem:
How many servers are available out there and who manages them ?
One central server mean a server able to take the load, both in term of requests (all developers from all projects can make many queries on a fairly regular base), and in term of "on-server" FitNesse-related computations.
Another criteria is the visibility. Do your development projects need to see each other FitNesse indicators ? For "political" reason, some of those indicators may not be always welcome to be seen at all time by the rest of the projects! Some project manager might want to keep them close to the vest and control their official communication.
Actually, it is for the latter reason our FitNesses wikis are managed by each teams, more as an internal tool. We have another global wiki (based on Confluance), for managing global documentation for each projects. Those common wikis may extract some of the internal FitNesse wiki data.