Конвейер сборки Azure DevOps - сбойная сборка по-прежнему развертывается в Azure

Я пытаюсь создать конвейер CI / CD для примера прототипа. Таким образом, я начал достаточно просто, чтобы протестировать свою инфраструктуру - я использую почти нетронутый шаблон веб-приложения ASP.NET Framework (таргетинг на 4.6.1). Я выполнил следующие шаги:

  • Приложение развернуто в службе приложений Azure.
  • Его контроль версий размещен в Azure DevOps.
  • Был создан, настроен и протестирован конвейер сборки со следующими задачами, если он выполняется (задачи и их порядок взяты из шаблона):

Используемые задачи

  • Параметры / параметры развертывания Azure привязаны к репозиторию DevOps, поэтому сборки также отображаются в Azure и должны быть развернуты там в случае успеха.
  • Конвейер сборки привязан к правильному репозиторию внутри DevOps.
  • Сборки запускаются нажатием на главную ветку

Следующим шагом было убедиться, что сломанная сборка из-за неудачных тестов или по любой другой причине не развернута в производственной среде в Azure. По этой причине я создал неудачный тест.

И здесь я в тупике. Сборки действительно завершаются сбоем, как и ожидалось, и задача «Развертывание службы приложений» пропускается, потому что задачи сборки, предшествующие ее возникновению, имеют сбой:

Ошибка развертывания

Тем не менее, эти неработающие сборки по-прежнему развертываются в Azure и в производственной среде, даже не дожидаясь завершения конвейера. Я проверяю, что изменение действительно произошло, с небольшими визуальными обновлениями.

Сборка начинается и завершается в Azure, как только происходит push, прежде чем конвейер в DevOps будет полностью пройден (или даже запущен, если поиск агента занимает больше времени):

Создание на базе Azure

Построен

(DevOps еще не закончен):

И все же конвейер еще не закончен ...

Что я здесь делаю не так? Я неправильно понимаю конвейер? Я где-то пропустил этап настройки? Я потерялся.

Изменить. По просьбе Джоша, вот и мой триггер: введите описание изображения здесь

Изменить 2.2. Еще немного разъяснений по поводу моих вариантов развертывания в моей службе приложений в Azure, связанных с комментариями Дэниела:

введите здесь описание изображения

Это оказалось проблемой.

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


person Derptastic    schedule 11.10.2018    source источник
comment
Можете ли вы поделиться информацией об артефакте конвейера выпуска и триггере CI?   -  person Josh    schedule 11.10.2018
comment
@Josh Я использую только конвейер сборки, я еще не настроил отдельный конвейер выпуска.   -  person Derptastic    schedule 11.10.2018
comment
У вас есть что-то на этапе сборки VS, которое передает аргументы MSBuild, которые развертывают приложение? Потому что, если он говорит, что задача пропущена, задача определенно пропущена. Так что должно быть что-то еще, что развертывает приложение, и единственный виновник, о котором я мог думать, это VS Build.   -  person Daniel Mann    schedule 12.10.2018
comment
@DanielMann Это тоже была моя первоначальная мысль, но самое странное, что оба процесса запускаются параллельно. Когда я нажимаю на главную ветвь, одновременно запускаются и сборка в конвейере DevOps, и сборка на портале Azure. Сборка в Azure завершена (и веб-сайт обновлен) еще до того, как конвейер дойдет до этапа сборки решения, поэтому я удалил его из своего списка виновных.   -  person Derptastic    schedule 14.10.2018
comment
@DanielMann Мои аргументы MSBuild: / p: DeployOnBuild = true / p: WebPublishMethod = Package / p: PackageAsSingleFile = true / p: SkipInvalidConfigurations = true / p: PackageLocation = $ (build.artifactstagingdirectory) \\ Я хотел бы указать три вещи. 1) / p: DeployOnBuild = true может показаться проблемой, но, как я уже упоминал, сборка в Azure запускается, как только происходит push, еще до того, как мы дойдем до этого момента. 2) Изменение на false не помогает. 3) Я просмотрел учебник для того же процесса с теми же шагами, и там он установлен на true и все еще работает, как ожидалось.   -  person Derptastic    schedule 14.10.2018
comment
Что вы имеете в виду под сборкой на портале Azure? Если у вас подключена какая-то другая внешняя система, которая строит что-то, это ваш виновник.   -  person Daniel Mann    schedule 14.10.2018
comment
@DanielMann Я имел в виду, что мои варианты развертывания на портале Azure (моя служба приложений) привязаны к Azure DevOps. Теоретически, когда конвейер сборки переходит на этап развертывания службы приложений Azure и он оказывается успешным, он развертывается в Azure, который затем обновляет сборку для размещенной на нем службы приложений. За исключением того, что сборка обновляется, как только я отправляю что-то в главную ветку, а не когда конвейер достигает соответствующего шага. Я добавлю снимок экрана с моими вариантами развертывания и немного дополнительных разъяснений.   -  person Derptastic    schedule 14.10.2018
comment
@Derptastic Я могу ошибаться в этом (но я не думаю, что я ошибаюсь): развертывание, которое вы настроили на портале Azure, привязано только к системе управления версиями, а не к вашему определению сборки. Таким образом, каждый раз, когда вы фиксируете систему управления версиями, происходят две вещи, которые полностью не связаны друг с другом и происходят параллельно: 1) запускается сборка и 2) веб-сайт Azure обновляется версией, которую вы только что отправили в систему управления версиями. Удалите №2, и ваша проблема исчезнет.   -  person Daniel Mann    schedule 15.10.2018
comment
@DanielMann Нет. Вы не ошиблись. Большое спасибо! =) Так что в итоге все свелось к тому, что я дебил. Не могли бы вы опубликовать его в качестве ответа, чтобы я мог принять его и отметить проблему как решенную? И на случай, если кто-то задается вопросом, почему параметры развертывания были настроены с самого начала: я начал постепенно, сначала настраивая развертывание из ветки напрямую, а затем переходя к конвейеру (но, видимо, нужно было отключить первую настройку , чего я не делал).   -  person Derptastic    schedule 15.10.2018


Ответы (1)


Развертывание, которое вы настроили на портале Azure, привязано только к системе управления версиями, а не к вашему определению сборки. Таким образом, каждый раз, когда вы фиксируете систему управления версиями, происходят две вещи, которые полностью отключены друг от друга и запускаются параллельно, поскольку они прослушивают один и тот же репозиторий на предмет изменений:

  1. В конвейере запускается сборка.
  2. Веб-сайт Azure обновляется до версии, которую вы только что отправили в систему управления версиями, поскольку с ней привязаны параметры развертывания.

Удалите №2, и ваша проблема исчезнет. Вы устанавливаете службу приложений, которую хотите обновить, в конвейере, вам не нужен дополнительный перехватчик в самой службе приложений.

person Daniel Mann    schedule 15.10.2018