0

我们目前使用 Visual Studio 发布管理工具来管理代码的发布阶段。目前,我们正在使用基于操作的旧模板,这需要在每台目标机器上安装专用的部署代理。未来,我们计划使用 Desired State Configuration 方法,但我偶然发现了一个我现在无法自己回答的问题。我怀疑这也适用于 DSC 管道,但我现在专注于基于动作/组件的管道。

在 RM 中,您只能将动作和组件放置在机器范围内。您有安装了部署代理的服务器,可以在管道中选择,它们是工作流中的基本实体。一切都在这些机器范围内。

但是我们现在有一个发布要求,它本身不是安装。我们想要自动化的操作之一是在 google play 中发布一个 android apk,但这不依赖于任何特定的机器,因为它不安装任何东西。它需要 apk 本身,它位于我们的放置文件夹中,但不需要将其复制到我们的任何机器上。

由于 RM 不允许将操作和组件放置在机器范围之外,那么在工具内运行独立于机器的发布操作的策略是什么?我曾考虑将部署代理安装在与 RM 服务器相同的机器上,并使用另一个机器范围“localhost”来执行此操作,但这似乎很复杂。

我想要的与 TFS Build 的工作方式非常相似。当构建工作流启动时,它在构建控制器上运行,您可以在该范围内放置任何活动。然后,在工作流的某个时刻,它开始在构建代理中运行任务。RM是否有类似于“在控制器本身上运行”的东西?

4

1 回答 1

1

您的方法是我通常使用的方法......我称之为“跳板”服务器。我将其用于诸如通过 DSC 配置虚拟机作为部署目标,或者针对新部署的环境运行集成测试。这并不理想,但它具有功能性且微创。

我建议您将跳板服务器设置为功率相当低但专用的 VM。您不希望有人不小心弄乱了您的 RM 服务器的 IIS 安装!

DSC 可能不会有这个问题;至少在更新 3 中的实现中,您可以将操作置于机器范围之外。使用 DSC,您可以指定一个额外的“配置”脚本,其中包含充满目标节点的关联数组,允许您将节点配置与所需的状态脚本分开。

于 2014-10-21T22:05:59.967 回答