如何在实验室管理和发布管理之间共享部署代码

Question

在刚开始使用 Microsoft Release Management 之后，我越来越确信它不太适合运行集成测试。这可能是我的一种错误感觉，我很想在this 上获得更多信息。当我们第一次考虑它时，我打算通过它的管道运行我们测试计划中定义的测试，但现在我看到我们应该尽可能频繁地运行这些测试。我们希望每晚都运行集成测试，但我们的候选发布版本仅在 sprint 结束时定义，因此使用发布管理似乎有冲突。

有了这个等式之外的工具，我们正在考虑再次探索实验室模板。几个月前，我们在一个遗留项目中对其进行了一些非常小的测试，但从未走得太远。我现在主要担心的是两个阶段都需要部署：

• 发布管理管道需要将我们的项目部署到 QA 和生产环境中
• 实验室模板还需要在几个虚拟机上部署项目以运行集成测试

发布管理使用一些非常好的抽象来实现这一点。您可以根据放置文件夹结构对机器范围进行编码并定义组件，以定义要部署的整个应用程序的每个部分。另一方面，实验室管理工作流程不支持这一点（或者我可能只是想念它）。为实验室测试进行部署的标准方法是编写一个自定义的 power shell 脚本，将文件从构建放置文件夹移动到正确的位置，为 Web 项目创建应用程序池，以及类似的东西，所有这些都是手动完成的。

理想情况下，我只想在这两个工具之间共享整个部署工作流程，而且由于发布管理的执行方式看起来要简单得多，我会使用它。这将使同时维护两个管道变得更容易，我认为这实际上是司空见惯的。

在两个工具之间尽可能多地共享部署代码的正确方法是什么？

Answer 1

我希望 RM 和 MTM/LM 之间更好的集成将成为未来的功能。在此期间，您可以调查使用 Desired State Configuration 来处理为您配置环境的单个脚本。

在 RM Update 2 中，DSC 支持并不是真正开箱即用的，但 RM Update 3 将内置对 Azure 和本地 VM 的 DSC 支持。更新 3 CTP 1 现已发布，但尚未准备好生产。

您仍然可以在更新 2 中使用来自 RM 的 DSC，只是需要做更多工作。