1

一段时间以来，我们一直在使用 TFS 2010 来管理工作项和 sprint，并且最近增加了一个专门的 QA 人员。我需要做的是创建一个可以按计划运行的构建定义（例如星期二晚上 9 点），它只会构建和/或部署处于“ReadyToDeploy”状态的工作项. 或者一种基于 TFS API 获取要推送的文件列表的方法。

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

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

我对任何想法或解决方案持开放态度，另一种选择是我必须每周管理文件列表并手动推送文件，我正试图摆脱这种情况。

谢谢，

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

4

3 回答 3

0

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

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

我们多年来一直经营类似的东西，它对我们来说效果很好。很多人会告诉你这是不好的做法，而且很可能是这样，但这是你自己决定的。

至于自动化构建，我认为这不是一件容易的事。最困难的部分将是合并。您可能认为不会有冲突，因为它是单向合并，但是这样做了很多年，我可以告诉您确实会出现冲突。

分步说明

  1. trunk创建一个被调用的分支release
  2. 当您想要进行部署时，从trunkinto合并release，但只挑选ReadyToDeploy变更集。这可能需要多次合并，因为变更集必须是连续的。
  3. 启动发布分支的构建/部署。
  4. 在发布计划允许的情况下重复步骤 2 - 3。
于 2013-03-06T16:29:08.957 回答
0

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

  1. 设置使用 TFS API 扫描处于该状态的项目的进程
  2. 使用 API 遍历项目以附加签到
  3. 使用 API 获取最新的源分支和目标分支
  4. 使用 API 通过变更集进行合并（在 #2 中确定）（这很重要，必须处理很多情况，但合并应该是一种没有冲突的方式，所以可行）
  5. 使用 API 签入
  6. 开始编译构建
  7. 如果编译构建成功启动发布构建
于 2013-03-06T18:19:58.440 回答
0

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

于 2013-10-17T22:40:17.600 回答