tfs - 使用 Azure DevOps 共享部署组，Web 应用程序正在被覆盖，如何才能最好地调试呢？

Question

上下文

我有一个安装了单个部署代理的本地 TFS (Azure DevOps) 服务器（版本 2018.2）。

此代理位于共享部署组中，用于部署多个 IIS Web 应用程序，每个应用程序驻留在自己的项目和发布管道中。

发布管道都使用相同的流程，运行IIS Web 应用部署模块来部署每个应用程序。

在部署参数中，每个应用程序都有自己的唯一virtual application指定。

问题

部署一个应用程序时，它会正确部署到其唯一的虚拟应用程序，但代理配置为部署的所有其他虚拟应用程序即使在其他发布管道中也会被一个应用程序覆盖。

我试过的

1. 验证每个virtual application参数实际上在配置中是唯一的
2. 已验证任何给定部署的发布部署日志均未提及任何额外的部署路径。这尤其令人困惑，因为日志表明该操作仅正确部署到一个虚拟应用程序。
3. 检查目标服务器上的任何奇怪的 IIS 日志

问题

调试此类 Azure DevOps 问题的最佳后续步骤是什么？这是一个本地服务器，因此与云托管相比，我拥有更高级别的访问权限。

我在想也许：

1. 检查代理版本并将其更新到最新？
2. 是否还有其他包含有价值信息的日志？在目标服务器上？在 DevOps 服务器上？

标签： tfsazure-devopsazure-pipelinesazure-devops-self-hosted-agentazure-devops-server

Answer 1

我解决了这个问题。请参阅下面的书面过程。

解决方案

问题不在于部署模块，而是我错误地配置了紧接在每个部署模块之前运行的IIS 管理模块。每个管理模块physical path为每个虚拟应用程序设置了相同的参数值，这导致每次部署都会覆盖任何以前的部署。

调试过程

在 github 上为此编写相应的问题时，具有讽刺意味的是，有一个指向 AzureDevops 故障排除说明的链接，因此我开始关注该文档。

1. 我通过将变量添加到发布管道system.debug并将其设置为true.
   • 从这里我可以看到，事实上，没有其他虚拟应用程序被部署到
2. 我检查了目标服务器上代理安装目录下名为_diag.
   • 这表明一切正常
3. 仍然不相信，我查看了源代码，发现所有模块都在运行 MsDeploy。
   • 这让我想知道是否所有的部署都在同一个物理位置
4. 然后我查看了IIS 管理模块的配置，发现我为每个虚拟应用程序设置了相同的物理路径。
5. 我通过为每个应用程序设置不同的物理路径来测试假设，并且，是的，应用程序不再相互覆盖！