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

Question

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

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

• 发布管理管道需要将我们的项目部署到QA和生产环境中
• Lab还需要将项目部署在几台虚拟机上，以便在

发布管理使用了一些非常好的抽象来实现这一点。您可以根据drop文件夹结构编码机器作用域和定义组件，以定义要部署的整个应用程序的每个部分。另一方面，实验室管理工作流不支持这一点(或者我只是错过了它)。让部署用于实验室测试的标准方法是编写一个定制的power shell脚本，将文件从build drop文件夹移到正确的位置，为web项目创建应用程序池，诸如此类的东西，都是手工完成的。

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

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

Answer 1

我希望RM和MTM/LM之间更好的集成将是未来的特性。在此期间，您可以使用所需的状态配置来研究如何处理为您配置环境的单个脚本。

DSC支持并不是真正的开箱即用的RM更新2，但RM更新3将内置支持DSC到Azure和on-prem VM。更新3 CTP 1现在已经发布，但还没有准备好生产.

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