我们刚刚开始为我们的一个项目使用 Visual Studio Release Management，但我们的工作方式已经遇到了一些问题。
目前，我们已经创建了一个单一的发布阶段，负责将我们的构建工件部署到专用虚拟机进行测试。我们打算稍后使用这台机器运行我们的集成测试。
现在，我们有一个门控 checkin 构建过程:每次 checkin 都会触发所有单元测试，并且我们还将发布触发器配置为在此构建上发生。起初，似乎合理的是，在每次 checkin 后，都会部署项目并执行集成测试。我们注意到所有已发布的版本都在发布管理上污染控制台，并且所有版本都被标记为“无限期保留”并且我们的放置文件夹位置正在快速增长(看到之后，该工具自动执行此操作是有道理的，因为可以将任何构建提升到另一个阶段，并且需要保留工件)。
那么问题是:我们做错了什么？我一直在考虑这个问题，“释放”每次签到真的没有任何意义。我们可能应该在 sprint 结束时开始这个发布过程，这一点可以被视为“发布候选”。
如果我们这样做，我们将如何以及何时运行我们的自动化集成测试？我的意思是，在我们的案例中运行这些需要一个部署过程，如果我们尝试使用其他方法来实现这一点(如 LabTemplate 构建过程)，我们最终将重复部署代码。
这里最好的方法是什么？
最佳答案
如果不进入您的组织并了解您的行事方式，很难说，但我会试一试。
首先，我通常会避免门控 checkin 构建，除非经常出现构建损坏的问题。如果损坏的构建不是痛点，请不要使用门控 checkin 。为什么？很简单:如果您的构建/测试过程需要 10 分钟才能运行，那么我必须等待 10 分钟才能知道我是否可以继续工作，或者我是否要让我的更改被踢回去。它不鼓励小的、频繁的 checkin ，并鼓励大量的、无上下文的 checkin 。
开发者 B 还需要等待 10 分钟才能获取开发者 A 的最新更改。如果开发人员 B 需要 checkin 才能继续工作，那就是浪费时间。相信您的 CI 流程能够捕获损坏的构建，相信您的开发人员会承担责任并在它们发生的极少数情况下修复它们。
更合适(取决于您的分支策略)对您的主干进行门控 checkin ，然后 CI 对您的开发/功能分支进行构建。当然，这打开了整个“当我有多个分支时如何构建一次/部署多个？”可以蠕虫。 :)
如果您的集成测试很慢并且需要部署才能成功，那么它们可能不适合作为 CI 的一部分运行。拥有一个 CI/gated checkin 构建，它只是:
- build
- 运行快速单元测试
- 运行高优先级、非基于部署的集成测试
然后，进行第二次构建(预定或滚动)，实际部署并运行整个测试套件。您可以根据自己的喜好安排时间——我通常在中午(或团队中“午休时间”的任何时间)安排一个，然后在午夜安排一个。这样你就可以从上午的工作中得到一个经过测试的构建，一个从下午的工作中得到。
使用发布默认模板，您可以将计划的构建定位到“开发”(/test/integration/无论您怎么调用它)阶段。当您准备好实际发布构建时，您可以使用针对生产的特定构建启动新版本，并让它正常通过所有阶段。
关于tfs - 我什么时候应该 "Release"我的构建？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23768762/