TFS 2010在某个州建立工作项目

时间:2013-03-06 15:37:58

标签: tfs msbuild tfs2010

我们一直在使用TFS 2010来管理工作项目和冲刺,并且最近在专门的QA人员上添加了。我需要做的是创建一个我可以按计划运行的构建定义(例如星期二晚上9点),它只构建和/或部署处于“ReadyToDeploy”状态的工作项。或者根据TFS API获取要推送的文件列表的方法。

我的最终目标是有一种方法来自动化发布过程,以便只有已通过QA的项目每周发送到我们的临时环境。然后,客户或QA可以批准这些项目在作为生产镜像的分段中工作,而另一个流程或构建定义将部署那些将处于不同状态的项目。

我已经修改了工作项和工作流来完成不同的状态,但是我遇到的问题是根据工作项的状态获取修复程序的构建或所有要推送的文件的列表。

我对此有任何想法或解决方案,另一种选择是我必须每周管理文件列表并手动推送文件,我试图摆脱它。

谢谢,

编辑:我们现在设置它的方式是每个开发人员都有自己的分支和自己的网站,我们的软件是基于服务器的,必须在特定的服务器上运行。我们的主干链接到主开发网站。这是QA最初进行测试以将项目移动到准备部署状态的地方。当开发人员准备好QA时,他们会检查他们的分支中的更改并合并到主干中。目前,构建是从主干创建的。在我们的部署之夜,我在VS中打开trunk网站并进行发布,然后将这些文件与开发人员给我的列表进行比较,并将编译后的文件ftp到我们的生产服务器。

3 个答案:

答案 0 :(得分:0)

我可能是错的,但我不知道如何告诉构建版本根据附加工作项的状态来避免某些更改集。

我认为实现这一目标的唯一方法是创建一个Release分支并执行每天合并处于“ReadyToDeploy”状态的变更集。合并时,您可以选择更改集,但它们必须是contiguous。这意味着您必须执行多次合并才能使Release分支进入适当的条件。

我们已经经营了多年的类似事情,对我们来说效果很好。许多人会告诉你这是不好的做法,而且可能是,但这是由你来决定的。

至于构建的自动化,我认为这不是一项微不足道的工作。最困难的部分将是合并。您可能会认为不存在冲突,因为它是单向合并,但多年来已经这样做了,我可以告诉您冲突确实会发生。

逐步说明

  1. 从名为trunk
  2. release创建分支
  3. 如果要进行部署,请从trunk合并到release,但只能选择ReadyToDeploy更改集。这可能需要多次合并,因为变更集必须是连续的。
  4. 触发发布分支的构建/部署。
  5. 重复步骤2 - 3,因为您的发布计划允许。

答案 1 :(得分:0)

你可以自动做一些事情,这需要大量的编码。它还需要一个分支策略,以便Dev,Staging和Production都来自他们自己的分支。

  1. 设置使用TFS API扫描该状态项目的流程
  2. 使用API​​遍历项目以获取附加检查
  3. 使用API​​获取最新的源和目标分支
  4. 使用API​​通过更改集进行合并(在#2中标识)(这是非常重要的,必须处理大量案例,但合并应该都是单向的,没有冲突,所以可行)
  5. 使用API​​签入
  6. 启动Compile Build
  7. 如果编译构建成功启动发布构建

答案 2 :(得分:0)

据我所知,这种方法存在一个主要问题。假设您有两个变更集:#1和2.它们都包含对同一文件的修改。现在,变更集#2包含自己的更改以及来自#1的更改。 如果您决定引入变更集2并跳过#1猜测会发生什么。你将从#1中汲取变化。这显然是个问题。