我一直致力于为新一年的Team Foundation Server部署标准化源代码控制结构.我已经开始使用CodePlex上提供的Microsoft Team Foundation Server分支指导文档.
我希望得到一些反馈,并回答我对拟议结构的一些具体问题.在TFS中构建源代码控制时,我了解到有很多"标准"可供选择,因为没有真正的标准.
首先,我将概述和描述决策和用法.
$/
{Team Project}/
{Subproject}/
Development/
Trunk/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Integration/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Production/
Releases/
{Release Version}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
Branches/
{Branch Name}/
Source/
Tests/
Sandcastle/
TeamBuildTypes/
{Build Name}/
一般逻辑是团队项目可以包含单个逻辑项目(没有{Subproject}条目的地方)或产品或工具套件形式的多个相关项目.三大容器称为Development,Integration和Production.
在Development容器的Trunk中,可以为Source文件夹中的产品组成项目,并在文件夹中提供相应的单元测试Tests.大多数次要开发都会发生在主干中,通过Trunk文件夹的兄弟Branches文件夹提供分支,该文件夹充当分支容器.一个或多个解决方案文件将存在于其中Trunk,允许该级别的分支捕获解决方案,源和单元测试.
该Integration容器,经常在非TFS实现所谓的"主打",仅用于集成变更从Development创造稳定和可测试的版本.Development一旦获得可测试产品,它最初是作为容器的分支创建的.此容器的构建将用于我们的测试环境和负载测试环境.我们选择使用可测试版本进行负载测试,以便我们可以监控性能变化,从而快速隔离可能导致任何异常情况的变更集.
Production用于生产预生产和生产质量的建筑.Integration一旦建议发布稳定版本,它最初是作为容器的分支创建的.在该Releases文件夹中,遵循"按发布分支"结构,在单个位置提供快照和隔离.(例如,当Release 1.1准备进行预生产构建时,稳定Integration容器将分支到结构中的新Release 1.1文件夹中Production/Releases.后续RC和RTW/RTM也会被提升到此文件夹中.)还存在分支结构,如Branches容器中所见.这允许"修补程序",通常是修订标记(Major.Minor.Revision).分支是从当前版本创建的,并合并回新的修订标记 - 就像Release 1.1.1.Changeset将在接受后反向集成到Development容器中Trunk.
我们认为这种结构在稳健性和复杂性之间是一种公平的平衡.但是有一些唠叨的问题我无法在逻辑上融入模型.他们是:
团队建设 -在Development和Integration容器将首先开始了为每晚构建,最终转向持续集成(CI).生产容器将手动构建.
构建定义应该在哪里生效？ 编辑 - 基于几个响应,TeamBuildTypes文件夹已移至主干并分支到相应的容器.然而,这确实导致了一个新问题(如下).
通过将TeamBuildTypes文件夹放在适当的容器中,这是否意味着所有构建定义将在相应的文件夹之间重现？例如,具有开发质量构建的构建定义以及可测试构建等,所有构建定义都存在于整个结构中的所有TeamBuildType文件夹中.
文档生成 - 我们使用Sandcastle生成文档.具体来说,我们还使用Sandcastle帮助文件生成器来管理输出.这将生成特定于SFHB格式的项目文件.
生成的文档应该存储在源代码管理结构中吗？
是否应为每个容器生成文档,还是仅为预生产和生产质量构建提供价值？
为了保持快速的本地构建时间,文档创建是否应该由构建定义拥有？
SHFB特定文件应该在哪里存在？我最初的想法是把它作为对象 我同意,这是一个对等方recommondations Source和Tests文件夹.Source和Tests.图表已更改以反映此更改.
第三方二进制文件
二进制文件(控件,库等)是否应存储在源代码管理中？
如果是这样,它应该是自己的团队项目吗？
常规文档 - 源代码管理结构中的文件夹不会反映非生成的文档,例如需求,设计文档,测试计划等.在与我的开发人员和同事进行一些研究和讨论之后,使用团队资源管理器中的内置Documents文件夹可以提供更多好处,因为它反映了团队项目门户中的结构,而一些(业务)用户不需要额外的复杂性来学习TFS的源控制方面.
我将更新结构,因为我得到问题的答案,以提供更清晰的图片.我也欢迎任何与潜在变化有关的评论.如果我有任何其他问题,我会确保修改这篇文章.
编辑:
澄清. Source和Tests文件夹也存在于Integration容器下.
Micah和Josh都提出了关于第三方二进制文件的重点.关于这个问题的问题.
文档生成可能很慢.关于文档创建是否应归特定团队构建类型所有的问题.
添加了与非生成文档相关的解决方案,例如需求,设计文档,测试计划等.
添加了与TeamBuildTypes文件夹相关的解决方案以进行构建定义.
根据各种反馈,将TeamBuildTypes文件夹移动到主干/分支级别.
JoshBerke.. 6
我喜欢你将Sandcastle文件作为对象进行源和测试的想法,我会添加一个文档文件夹,然后包含sandcastle文件,以及可选的实际文档.
意见存在明显差异,我相信我会因此而被投票(因为我以前).我将生成的文档放在TFS中有几个原因:
您希望在每个版本中使用您的文档,并使用TFS是一个简单的方法,以确保您的文档保持在正确的位置.
使用TFS存储它意味着每个人都知道去哪里获取文档.
有一件事我不知道我一直在努力争取的是第三方依赖的地方,可能是因为它们属于源代码所以它们与每个项目有关,尽管如果你想在项目中分享它们你可以添加一个新的顶部级别节点.
编辑对于我的二进制文件,我通常最终得到
$ /第三方/公司/产品/版本/ src目录(可选)
所以我举个例子
$/ThirdParty/Microsoft/EntLib/3.1 4.0 ComponentArt/WebUI/2008.1/Src
我想添加源代码,我不得不修补我不喜欢的CA源代码,但是当第三方不修复bug时你必须诉诸于此.
我喜欢你将Sandcastle文件作为对象进行源和测试的想法,我会添加一个文档文件夹,然后包含sandcastle文件,以及可选的实际文档.
意见存在明显差异,我相信我会因此而被投票(因为我以前).我将生成的文档放在TFS中有几个原因:
您希望在每个版本中使用您的文档,并使用TFS是一个简单的方法,以确保您的文档保持在正确的位置.
使用TFS存储它意味着每个人都知道去哪里获取文档.
有一件事我不知道我一直在努力争取的是第三方依赖的地方,可能是因为它们属于源代码所以它们与每个项目有关,尽管如果你想在项目中分享它们你可以添加一个新的顶部级别节点.
编辑对于我的二进制文件,我通常最终得到
$ /第三方/公司/产品/版本/ src目录(可选)
所以我举个例子
$/ThirdParty/Microsoft/EntLib/3.1 4.0 ComponentArt/WebUI/2008.1/Src
我想添加源代码,我不得不修补我不喜欢的CA源代码,但是当第三方不修复bug时你必须诉诸于此.
京公网安备 11010802040832号 | 京ICP备19059560号-6 