Базовый поток разработки Azure для ASP .Net - PullRequest
Новая
       9

Базовый поток разработки Azure для ASP .Net

0 голосов
/ 22 июня 2019

У меня есть стандартный способ работы для сборки и развертывания приложений asp .net на сервере сборки (обычно Jenkins). У меня есть собственный сценарий сборки и я публикую профиль, который строит мое решение, копирует некоторые файлы и публикует веб-проект с помощью всего одного вызова MSBuild.

Я пытаюсь воссоздать это в Azure DevOps. Мое первое препятствие, кажется, состоит в том, что сборка и «публикация» (или «релиз» на языке DevOps) - это отдельные шаги. Но кажется, что мне не нужно «публиковать»?

Итак

  1. Как мне управлять тем, что попадает в папку "артефакты" сборки? Это через Azure? Могу ли я сделать это с файлом .MSBuild? И
  2. Нужно ли вообще понятие «публиковать» или шаг выпуска просто копирует все артефакты в место назначения (в данном случае виртуальную машину)? Могу ли я контролировать то, что развертывается?

Мне трудно найти какое-то базовое руководство, которое охватывает проекты asp .net, развертываемые таким образом.

Ответы [ 2 ]

0 голосов
/ 24 июня 2019
  1. Как мне управлять тем, что заканчивается в папке "артефакты" сборки?Это через Azure?Могу ли я сделать это с файлом .MSBuild?

Да, мы могли бы использовать параметр аргументов MSBuild /p:PackageLocation=$(build.artifactstagingdirectory) для управления тем, что заканчивается в папке "артефакты".

Когда мы используем задачу сборки Visual Studio для сборки проекта, мы можем изменить параметр MSBuild Arguments следующим образом: /p:DeployOnBuild=true /p:PublishProfile=Test /p:PackageLocation=$(build.artifactstagingdirectory)

Затем мы можем использовать задачу Опубликовать артефакты сборки , чтобыопубликовать артефакты сборки в конвейерах Azure, TFS или в общей папке.

Нужно ли вообще понятие «публикация» или шаг выпуска просто копирует все артефакты в место назначения (в данном случае виртуальную машину)?Могу ли я контролировать то, что развертывается?

Да, вы можете просто понять шаг выпуска, просто скопировав артефакты в место назначения.Если вы хотите контролировать то, что развертывается, вы можете отфильтровать артефакты при использовании задачи копирования с содержимым.

Проверьте статью Развертывание веб-приложений с помощью Team Build и Release Management для деталей.

Надеюсь, это поможет.

0 голосов
/ 22 июня 2019

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

Это обычная практика, хотя отделять сборку от публикации. Таким образом, вы можете добавить дополнительные проверки, обзоры и утверждающие на стадии выпуска.

В вашем случае это будет означать:

  • Стадия сборки
    • Используйте MsBuild для создания и создания пакета публикации в виде папки или zip-файла.
    • Используйте задачу Publish Pipeline Artifact для сохранения этой папки или zip-файла
  • Стадия выпуска
    • Используйте задачу Download Pipeline Artifact, чтобы восстановить файл для публикации.
    • При необходимости используйте инструмент Infra as Code для подготовки целевой среды.
    • Используйте msdeploy.exe или другой инструмент для публикации пакета. При необходимости создайте и передайте файл настроек для переопределения определенных настроек.

Таким образом, вы можете иметь несколько этапов выпуска для генерации тестовых сред, временных сред POC и т. Д., Просто используя другой набор переменных и / или файл переопределения настроек.

В конвейерах Azure есть специальные задачи, которые охватывают эти инструменты и предоставляют простой в использовании интерфейс и некоторую дополнительную логику. Это может быть очень полезно, если вы не обладаете глубокими знаниями об инструментах командной строки. Если вы знаете, как их обходить, у вас может не быть веской причины использовать необычные задания.

...