При использовании CI / CD в VSTS шаг публикации должен быть частью сборки или «выпуском»?

Question

У меня есть проект VSTS, и я сейчас настраиваю CI / CD. Все хорошо, но у меня, похоже, есть 2 варианта шага публикации:

Вариант 1: это задача в составе CI Build, например, см. шаг сборки 3 здесь: https://medium.com/@flu.lund/setting-up-a-ci-pipeline-for-deploying-your-angular-application-to-azure-using-visual-studio-team-f686c8f190cf

Вариант 2: фаза сборки создает артефакты, и как часть отдельной фазы выпуска эти артефакты публикуются, см. Здесь: https://docs.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts

Обе опции хорошо поддерживаются в документации MS, один из этих вариантов лучше, чем другой? Или это случай за и против для каждого, и это зависит от обстоятельств и т. Д.?

Спасибо!

Answer 1

Почти все задачи сборки совпадают с задачами выпуска, поэтому вы можете развернуть приложение после сборки проекта в процессе сборки.

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

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

Что касается задачи публикации артефакта, она используется для публикации файлов на VSTS-сервере или в другом месте (например, в общей папке), которую можно использовать в выпуске как артефакт (нажмите Добавить артефакт> Построить в определении выпуска), вы также можете скачать их для устранения неполадок, например, если вы используете размещенный агент, к которому у вас нет доступа, но вы хотите получить некоторые файлы (например, результат сборки), вы можете добавить задачу публикации артефакта для публикации на VSTS-сервере, а затем загрузить их (Открыть результат сборки> Артефакты)

Answer 2

Вы обязательно должны использовать «Вариант 2». Ваша сборка не должна вносить изменений в вашу среду, это именно то, что является «релизом». Эта ссылка в «Варианте 1» - неправильный способ сделать это, сборка должна быть именно такой: компиляция кода и создание артефактов, а не развертывание кода на самом деле.

Когда вы комбинируете сборку / релизы вместе, вы очень усложняете отладку проблем сборки. Поскольку ваш код всегда выпускается, вам действительно нужно отключить шаг «развертывания», чтобы получить представление о том, что было построено до развертывания.

Кроме того, хорошая вещь в создании артефакта заключается в том, что у вас есть развертываемый пакет, и если в будущем вам потребуется откат к предыдущей рабочей версии, он готов к работе. Используя стратегию «только для сборки», вам придется вернуть свой код или сделать ненужные резервные копии, чтобы добиться этого.

Я думаю, вы найдете любую новую документацию Microsoft, указывающую на этот подход, и VSTS полностью настроен так. Даже функция «Настроить непрерывную доставку в Azure ...» в Visual Studio 2017 создаст сборку и выпуск.