TFS 2015（和 Octopus）：持续集成，但请稍等答案

【问题标题】：TFS 2015 (and Octopus): Continuous integration, but wait a bitTFS 2015（和 Octopus）：持续集成，但请稍等
【发布时间】：2016-05-22 18:21:15
【问题描述】：

完成拉取请求后，我们的（基于 TFS 2015/Octopus 的）构建系统将进行构建和部署。问题是，我们通常有一堆拉取请求排队，并且批准它们中的每一个都会触发构建和部署，创建/保存不必要的包并生成电子邮件给 QA 部署准备就绪。也许不是一个严重的问题，但可以肯定的是一个烦恼。

我们正在使用 vNext 构建定义。我启用了“批量更改”，但还不够好（构建需要不到一分钟，审查和批准拉取请求可能需要 1-30 分钟）。我想做的是持续集成，但是在第一次合并后等待 15 分钟，看看是否有任何其他变化。

或者，每小时进行一次计划构建，但前提是某些内容发生了变化。
或者，每次都构建，但 Octopus 只会在等待一段时间后部署，这也可以。

除了编写我自己的 Windows 服务，该服务使用 TFS REST API 仅在某些情况发生变化时每 x 分钟触发一次构建，我没有看到一个好的解决方案。或者我考虑过将构建包保存在某个地方，然后编写一个服务，仅当 x 分钟内没有新包到达时才将它们发送到 Octopus。

有人有这样的工作吗？

【问题讨论】：

“每小时进行一次预定的构建，但只有在发生变化时才足够” - 这似乎是构建 vNext 和 XAML 构建之间的差距。
Rolling builds 已更新为 Batch 选项，但 Build no more often than every X minutes 目前缺失。 See 1st comment in the blog post from VSTFS.

标签： tfs tfs-2015 octopus-deploy

【解决方案1】：

在我实施这一点的地方，我主张让 QA 团队决定何时（甚至如果）部署。我通常实现两种环境：

DEV 集成：每个持续构建都在这里部署。如果部署成功，则 QA 团队可以使用它（电子邮件、构建质量等）
QA 环境：QA 团队执行测试的地方。 QA 团队选择部署哪个版本以及何时部署。

您可以在 Octopus Deploy 中设置权限，以允许 QA 团队将构建从 DEV 环境“提升”到 QA 环境。不确定您是否有能力设置这样的第二个环境，但如果可以，它将为您提供很大的灵活性。

【讨论】：

我想过做这样的事情。我什至不需要单独的 DEV 服务器。我将每个部署都设置为部署到 QA 服务器上的新 IIS 站点（根据版本号命名）。我可以给 QA 一个脚本，让他们可以推广构建。它只会将站点绑定从“pending-blahblah.com”切换到“blahblah.com”
我过去也采用过这种方法 - 拥有两个环境可确保开发人员可以在 PR 之后检查他们的工作，然后再进行 QA 工作。

【解决方案2】：

我会在每次签入的基础上继续改进，以便开发人员有一个快速的反馈周期。

要解决您的问题，您可以编写一个 powershell/small 应用程序，使用 Octopus API 来查询最新版本是什么，看看它是否已部署到 QA，如果没有，部署它。然后，您可以使用 Windows 调度程序进行调度。

使用 C# 客户端库的示例代码（未测试）：

var project = _repository.Projects.FindByName("MyProject");
var qaEnv = _repository.Environments.FindByName("QA");
var release = _repository.Projects.GetReleases(project).Items.First();
var isDeployed = _repository.Releases.GetDeployments(release).Items.Any(i => i.EnvironmentId == qaEnv.Id); // Only returns the first 30 items, uses paging
if(!isDeployed)
    _repository.Deployments.Create(new DeploymentResource()
    {
        ProjectId = project.Id,
        ReleaseId = release.Id,
        EnvironmentId = qaEnv.Id
    })

【讨论】：