В общей группе развертывания Azure DevOps веб-приложения перезаписываются, как лучше всего отладить это?

Контекст

У меня есть локальный сервер TFS (Azure DevOps) (версия 2018.2) с одним агент развертывания установлен.

Этот агент находится в общая группа развертывания и используется для развертывания нескольких веб-приложений IIS, каждое из которых находится в своем собственном проекте и конвейере выпуска.

Все конвейеры выпуска используют идентичный поток, выполняющий Модуль IIS Web App Deployment для развертывания каждого приложения.

В параметры развертывания для каждого приложения указаны свои уникальные virtual application.

Эта проблема

Когда одно приложение развертывается, оно правильно развертывается в своем уникальном виртуальном приложении, но все другие виртуальные приложения, которые агент настроен для развертывания даже в других конвейерах выпуска, перезаписываются одно приложение.

Что я пробовал

  1. Проверено, что каждый параметр virtual application действительно уникален в конфигах
  2. Проверено, что в журналах развертывания выпуска для любого данного развертывания не упоминаются какие-либо дополнительные пути развертывания. Это особенно сбивает с толку, потому что журналы говорят, что операция правильно развертывается в только одном виртуальном приложении.
  3. Проверьте наличие странных журналов IIS на целевом сервере.

Вопрос

Каковы следующие шаги для устранения подобной проблемы Azure DevOps? Это локальный сервер, поэтому у меня более высокий уровень доступа, чем если бы он размещался в облаке.

Я думаю, возможно:

  1. Проверить версию агента и обновить до последней?
  2. Могут ли быть другие журналы с ценной информацией? На целевом сервере? На сервере DevOps?

tfs azure-devops azure-pipelines azure-devops-self-hosted-agent azure-devops-server
person David    schedule 14.04.2020    source источник
comment
Вы запускали развертывание с переменной system.debug, установленной на true?   -  person Daniel Mann    schedule 14.04.2020
comment
@DanielMann, я сделал, с теми же результатами. В журналах не упоминаются дополнительные пути развертывания, когда-либо указывается только одно виртуальное приложение.   -  person David    schedule 14.04.2020
comment
@David Не могли бы вы поделиться своим определением сборки?   -  person Cece Dong - MSFT    schedule 15.04.2020
comment
Спасибо @ CeceDong-MSFT. Я решил проблему с помощью Azure DevOps документ по устранению неполадок. Я опубликую свой процесс в качестве ответа.   -  person David    schedule 15.04.2020

Ответы (1)


arrow_upward
1
arrow_downward

Я решил проблему. См. Описанный ниже процесс.

Решение

Проблема заключалась не в модуле развертывания, а в том, что я неправильно настроил модуль управления IIS, который запускался непосредственно перед каждым модулем развертывания. У каждого модуля управления было одинаковое значение параметра physical path, установленное для каждого виртуального приложения, что заставляло каждое развертывание перезаписывать любое предыдущее развертывание.

Процесс отладки

По иронии судьбы, при написании соответствующей проблемы для этого на github была ссылка на инструкции по устранению неполадок AzureDevops, поэтому я начал следовать этому документу.

  1. I turned on verbose logging on the deployment agent by adding the system.debug variable to the release pipeline and setting it to true.
    • From this I could see that there were, in fact, no other virtual applications being deployed to
  2. I checked the additional agent logs on the target server under the agent install directory in a directory titled _diag.
    • This showed that everything was working correctly
  3. Still not convinced, I looked at the source code and found that all the module is doing is running MsDeploy.
    • This got me wondering if all the deployments were going to the same physical location
  4. Затем я просмотрел свою конфигурацию для модуля управления IIS и заметил, что я установил идентичные физические пути для каждого виртуального приложения.
  5. Я проверил гипотезу, установив разные физические пути для каждого приложения, и, ура, приложения больше не перезаписывали друг друга!
person David    schedule 15.04.2020