3

我们刚刚开始在我们的一个项目中使用 Visual Studio 发布管理，我们已经在如何做事上遇到了一些问题。

目前，我们创建了一个发布阶段，负责将我们的构建工件部署到专用虚拟机进行测试。我们打算稍后使用这台机器来运行我们的集成测试。

现在，我们有一个封闭的签入构建过程：每个签入都会触发所有单元测试，并且我们也将发布触发器配置为在此构建上发生。起初，在每次签入后，部署项目并执行集成测试似乎是合理的。我们注意到所有已发布的构建都污染了发布管理上的控制台，并且所有构建都被标记为“无限期保留”并且我们的放置文件夹位置正在快速增长（在看到之后，该工具自动执行此操作是有道理的，因为可以将任何构建提升到另一个阶段，并且需要保留工件）。

那么问题是：我们做错了什么？我一直在考虑这个问题，每次签到都“释放”确实没有任何意义。我们可能应该在 sprint 结束时开始这个发布过程，这一点可以被认为是“发布候选”。

如果我们这样做，我们将如何以及何时运行我们的自动化集成测试？我的意思是，在我们的案例中，运行这些程序需要一个部署过程，如果我们尝试使用其他方式来实现这一点（如 LabTemplate 构建过程），我们最终将重复部署代码。

这里最好的方法是什么？

4

3 回答 3

2

不要被“释放”这个词绊倒。在 MS 发布管理 (RM) 中，创建发布并不一定意味着您将将此代码交付给您的客户/甚至不意味着它具有退出开发的质量。这仅意味着您将代码的一个版本放在您的发布路径上。这个版本/发布可以在第一阶段停止，这没关系。

假设您有一个由 Dev、QA、Prod 组成的发布路径。在一个月的时间里，你最终可能会在 Dev 中发布 100 次，但在 QA 中只有 5 次，在 Prod 中只有一次。

您应该努力部署并测试每个签到。如果测试需要很长时间，则只在（门控或非门控）签入期间（例如，单元测试 + 部署）进行最少的测试，其余部分在发布路径的第二阶段（应在第一阶段完成后自动触发） ）。第二阶段是否需要很长时间都没关系。作为开发人员，签入，一旦构建成功完成（和第一阶段），期望其余的顺利进行并继续您的下一个任务。（请注意，只有第一阶段的结果会影响您的 TFS 构建）。

大多数情况下，部署和休息会运行良好，因此不会对开发产生任何影响。有时，您会在第一阶段失败，现在开发人员会中断他的新工作并尽快得到解决方案。

至于每次构建都无限期保留的问题，暂时是RM的副作用。当前客户需要手动进行清理（或编写脚本）。在即将发布的版本中，将制定新的版本/构建保留政策以改进这一点。这还没有工作，但目的是，例如，指示 RM 保留所有发往 Prod 的版本，只保留最后 5 个发给 QA 的版本，只保留最后 2 个发给 Dev 的版本。

于 2014-06-01T22:02:28.457 回答
2

如果不进入你的组织并看看你是如何做事的，这很难说，但我会试一试。

首先，我通常避免使用门控签入构建，除非经常出现构建损坏的问题。如果损坏的构建不是痛点，请不要使用门控签入。为什么？很简单：如果您的构建/测试过程需要 10 分钟才能运行，那么我必须等待 10 分钟才能知道我是否可以继续工作，或者我是否要让我的更改被踢回。它不鼓励小规模、频繁的签入，并鼓励大规模的、无上下文的签入。

开发者 B 也需要等待 10 分钟才能获取开发者 A 的最新更改。如果开发人员 B 需要该签入来继续工作，那是在浪费时间。相信您的 CI 流程可以捕获损坏的构建，并且您的开发人员会承担责任并在极少数情况下修复它们。

更适合（取决于您的分支策略）对您的主干进行门控签入，然后针对您的开发/功能分支构建 CI。当然，这打开了整个“当我有多个分支时，我如何构建一次/部署多个？” 可以蠕虫。:)

如果您的集成测试很慢并且需要部署才能成功，那么它们可能不适合作为 CI 的一部分运行。有一个 CI/gated checkin 构建，它只是：

  • 构建
  • 运行快速单元测试
  • 运行高优先级、非基于部署的集成测试

然后，进行实际部署和运行整个测试套件的第二次构建（计划的或滚动的）。您可以根据自己的喜好安排时间——我通常在中午安排一次（或团队中“午休”的任何时间），然后在午夜安排一次。这样你就可以从早上的工作中获得一个经过测试的构建，并从下午的工作中获得一个。

使用发布默认模板，您可以将计划构建定位到您的“开发”（/test/integration/无论您如何称呼它）阶段。当您准备好实际发布构建时，您可以使用以生产为目标的特定构建启动新版本，并让它正常通过所有阶段。

于 2014-06-01T14:19:16.263 回答
1

这不是一个简单的问题，因此也必须明确回答。

首先，你永远不会保留所有的构建；版本越老，对任何人的兴趣就越小；未在生产中部署的构建会被达到该阶段的构建所取代。

一个团队必须就使构建变得有趣的标准以及保留多长时间达成一致。为交付给生产或客户的构建定义策略：您支持它们多长时间？直到下一个版本，直到下一个版本，五年？潜在可交付的构建，仍然不在您的客户手中，被更新的版本取代，因此您可以使用数字或时间标准（TFS 仅实现第一个，因为第二个更容易出错）。通常，当您需要一个安全网选项并能够从一个可交付的池中进行选择时（具有更易于管理的错误的池），您通常有多个可交付的构建。

当您无法自动化之前的标准时，应使用 TFS“无限期保留”，因此您切换到手动实施的策略。无限期不是永远，意味着未知的时间间隔。

于 2014-05-21T07:41:03.163 回答