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