刚刚开始使用Microsoft Release Management后，我越来越相信它不适合运行集成测试。这可能是我的错误感觉，我希望在this上得到更多的意见。当我们第一次考虑它时，我打算通过它的管道运行我们的测试计划中定义的测试，但现在我看到我们应该尽可能频繁地运行它们。我们希望每晚都进行集成测试，但我们的发布候选版仅在sprint结束时定义，因此使用Release Management似乎存在冲突。
使用该工具，我们正在考虑再次探索实验室模板。几个月前，我们在遗留项目中对它进行了一些非常小的测试，但从未走得太远。我现在主要担心的是两个阶段都需要部署：
发布管理使用一些非常好的抽象来实现这一目标。您可以根据drop文件夹结构对计算机范围进行编码并定义组件，以定义要部署的整个应用程序的每个部分。另一方面，实验室管理工作流程不支持这一点（或者我可能只是错过了它）。使部署适用于实验室测试的标准方法是编写自定义电源shell脚本，将文件从构建放置文件夹移动到正确的位置，为Web项目创建应用程序池，以及类似的东西，所有这些都是手动完成的。
理想情况下，我想在两个工具之间共享整个部署工作流程，因为发布管理的方式看起来更简单，我会使用它。这样可以更容易同时维护两个管道，我认为这实际上是司空见惯的。
在两个工具之间尽可能多地共享部署代码的正确方法是什么？
答案 0 :(得分：2)
我希望RM和MTM / LM之间更好的集成将成为未来的特色。在此期间，您可以使用“所需状态配置”来调查是否只有一个脚本可以为您配置环境。
在RM Update 2中，DSC支持并不是真正的开箱即用，但RM Update 3将为Azure和本地虚拟机提供内置的DSC支持。更新3 CTP 1现在已经发布，但它还没有生产就绪。
你仍然可以在Update 2中使用来自RM的DSC，它只需要更多的工作。