这是我们上一篇文章(帮助构建VS2010解决方案/项目和TFS2010)的后续帖子。
关于如何构建我们的VS2010解决方案和项目以实现最佳组织,以及保存和使用TFS2010,我们有几个问题。
目前,我们的代码结构类似于:
/OverallAppName
OverallAppName.sln
-/Client
- -/WindowsFormsProject1
WindowsFormsProject1.sln
- -/WindowsFormsProject2
WindowsFormsProject2.sln
-/Components
- -/ClassLibrary1 (common library referenced by other projects)
ClassLibrary1.sln
- -/ClassLibrary2
ClassLibrary2.sln
- -/ClassLibrary3
ClassLibrary3.sln
- -/ClassLibrary4
ClassLibrary4.sln
- -/ClassLibrary5
ClassLibrary5.sln
-/Server
- -/WindowsServiceProject1
WindowsServiceProject1.sln
- -/WindowsServiceProject2
WindowsServiceProject2.sln
- -/WebProject1
WebProject1.sln
- -/WebProject2
WebProject2.sln
由于目前我们正处于从VSS迁移到TFS2010的过程中,我们希望将所有解决方案/项目构建为最高效,最合理,最易于维护,最易于参考和最简单的使用和构建TFS2010,我们需要一些关于使用分区解决方案模型构建所有内容的“最佳”方法的建议。
任何建议?????我们如何将所有这些不同类型的VS2010项目构建成一个逻辑结构,单独的组可以处理单个部分(而不是整个解决方案),我们仍然可以有项目引用,我们可以存储在TFS2010中并在那里构建和分支,以及遵循“推荐的最佳实践”?
感谢。 (对不起,我不确定格式是否非常好。)
答案 0 :(得分:0)
虽然我很钦佩你致力于将所有内容保持为一个大型解决方案,但我认为这将打破TFS在自动构建领域提供的一些最佳功能,并坚持这一点。
我之所以这么说,是因为您可以使用由签到触发的构建来立即构建代码以证明其有效(或者更好的是,使用Gated签到)。这些构建的有用性与它们运行所花费的时间成反比。因此,如果你有一个需要20分钟构建的大规模解决方案,那么它将会剥夺这些类型的构建的优势。但是,如果您有几个较小的解决方案,每个解决方案大约需要5分钟,那么您将只能在办理登机手续时获得修改后的解决方案并更快地了解结果。
根据您上面列出的内容,我倾向于为每套可以单独发布的文物提供解决方案。在您的示例中,每个客户端可能有一个,每个Web应用程序一个,所有公共库都有一个。
文件夹结构明智地与上面的内容没有什么不同(假设我正确地解释它)
/OverallApplication
/Clients
/Client1
-Client1.sln
/Client1Project1
-Client1Project1.csproj
/Client1Project2
-Client1Project1.csproj
...
...
/Components
-Components.sln
/ClassLibrary1
-ClassLibrary1.csproj
/ClassLibrary2
-ClassLibrary2.csproj
...
/Server
/WebApp1
-WebApp1.sln
/WebApp1Project1
-WebApp1Project1.csproj
/WebApp1Project2
-WebApp1Project1.csproj
...
...
/CodeSigningKey
-KeyPair.snk
/ReferencedAssemblies
/Manufacturer1
-Manufacturer1Assembly1.dll
...
...
公共库仍可作为项目引用添加到服务器和客户端解决方案中。我已经为常用项目引入了一些新文件夹,例如代码签名密钥和引用的第三方程序集(例如企业库)。
最重要的是,您需要采用某种分支策略来保持Main,Dev和Release代码分支的不同。我建议稍微阅读有关Codeplex的ALM Rangers分支指南。 http://vsarbranchingguide.codeplex.com/releases