Конвейеры выпуска Azure DevOps, YAML? [закрыто]

87

Я следую этому процессу, чтобы создать конвейер сборки YAML для проекта .NET Core Web API:

https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=vsts

Что касается его выпуска, я отмечаю, что (недавно переименованный) Azure DevOps, похоже, не поддерживает YAML для определения конвейеров выпуска. Однако я вижу, что задачи развертывания были определены, например:

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=vsts

Ожидаем ли мы обновления функциональности конвейеров выпуска для поддержки YAML, и если да, то когда?

Михаил12345
источник
Вскоре на Build 2019: youtube.com/watch?v=ORy3OeqLZlE Многоступенчатые конвейеры (и Release YAML) теперь в предварительной версии. Включите его в пункте меню Preview Features.
nullforce
2
Может ли кто-нибудь помочь мне понять, почему этот вопрос не по теме? Для меня это кажется хорошим вопросом для stackoverflow.
Tobske

Ответы:

59

На момент написания этого ответа временная шкала функций отражает релизы yaml в третьем квартале 2018 года.

https://docs.microsoft.com/en-us/azure/devops/release-notes/

Обновление: это было несколько раз. Рекомендуется проверять комментарии ниже, поскольку люди предоставляют обновления по мере их обнаружения.

Обновить

Согласно комментариям, теперь это возможно: https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/ . Следующее скопировано и вставлено из статьи и демонстрирует использование различных этапов:

stages:
- stage: Build
  jobs:
  - job: Build
    pool:
      vmImage: 'Ubuntu-16.04'
    continueOnError: true
    steps:
    - script: echo my first build job
- stage: Deploy
  jobs:
    # track deployments on the environment
  - deployment: DeployWeb
    pool:
      vmImage: 'Ubuntu-16.04'
    # creates an environment if it doesn’t exist
    environment: 'smarthotel-dev'
    strategy:
      # default deployment strategy
      runOnce:
        deploy:
          steps:
          - script: echo my first deployment
Джастин Холбрук
источник
9
Теперь он входит в состав функций Q4 2018.
sschoof
4
Есть рабочий элемент для отслеживания этого dev.azure.com/mseng/Azure%20DevOps%20Roadmap/_workitems/edit/…
sschoof 01
6
Вчера я связался через твиттер. В настоящий момент идет работа над определениями выпуска YAML, чтобы к концу марта он вышел в частную предварительную версию. Полная ветка на twitter.com/gopinach/status/1088320931745935360?s=21
rh072005,
5
Последний рабочий элемент, отслеживающий это - dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1364226
antmeehan
10
Ну наконец то! devblogs.microsoft.com/devops/whats-new-with-azure-pipelines 7 мая 2019 г.
Кэт Лим Руис
6

Опыт создания конвейера сборки YAML находится в предварительной версии. (сегодня 04.12.2018)

YAML для конвейеров выпуска, похоже, еще далеко : второй квартал 2019 г.

Функции предварительного просмотра можно включить из вашего профиля следующим образом:

меню профиля

Функция YAML

EDIT: как указывает nullforce в комментариях, это позволяет использовать YAML только для конвейеров сборки, но не для конвейеров выпуска.

ОБНОВЛЕНИЕ (2019-05-16): после Microsoft «Build 2019» полный опыт YAML для сборки и развертывания теперь должен быть возможен в том же файле конвейеров YAML.

Джим Вольф
источник
3
Этот вопрос касается конвейеров выпуска, а не конвейеров сборки. Указанная вами функция предварительного просмотра включает только конвейер сборки YAML.
nullforce 07
@nullforce Спасибо, я добавил ваше исправление к своему ответу и постараюсь поддерживать его в актуальном состоянии, если это включено для конвейеров выпуска или когда yaml также выходит из предварительной версии.
Джим Вольф
1
Это все еще недоступно.
ATL_DEV
@ATL_DEV не могли бы вы рассказать о состоянии или ссылку на ресурсы по этому поводу, чтобы я мог исправить ответ. Мне кажется, что это доступно: документы
Джим Вольф
@ Джим Вольф - Microsoft лжецы! Части выпуска и развертывания могут быть настроены только через его дурацкий интерфейс.
ATL_DEV
5

Команда продукта работает над этим. Вы можете отслеживать обновление через примечания к выпуску .

Стариан Чен-MSFT
источник
1
«Команда по продукту» ничего не сделала по прошествии 1 года. Пользовательский интерфейс Azure Dev Ops по-прежнему ужасен, а поддержка развертывания в yaml по-прежнему отсутствует, несмотря на все пустые обещания. Документация отсутствует и разбросана по сети, использование Azure Dev Ops просто ужасно! Microsoft должна найти чем-то еще, чем заняться,
ATL_DEV
Просто ради технической точности - несмотря на то, что в ноябре 2019 г. был опубликован комментарий о том, что поддержка YAML для развертывания «все еще отсутствует», на самом деле она была добавлена ​​в Azure DevOps (без места) в мае 2019 г. Другие ответы комментарии получают больше об этом. Просто хотел убедиться, что кто-то, читающий это, неправильно понял.
MikeBaz - MSFT
4

Я как раз сейчас делаю что-то подобное, но использую текущие REST API. То, что я делаю, похоже на то, что я описал здесь ( как импортировать определение выпуска в VSTS? ). В основном я сохраняю шаблонный файл JSON Release Pipeline в репозиторий исходного кода с переменными заполнителями и встроенным номером версии. Затем создайте сценарий PowerShell, который вызывает Azure DevOps (это длинное слово, я предпочел набирать VSTS, возможно, я начну печатать AD)

  • REST API для проверки Release Pipeline существует - работает
  • Создать, если его нет - работает
  • Сравните встроенные версии и обновите и, если необходимо (я застрял здесь, но я решу это, возвращая ошибку, что обновляемый конвейер не изменился, хотя я его изменил).

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

Antebios
источник
1
Я застрял и приостановил работу над процессом ОБНОВЛЕНИЯ. Почему? Шаблон json определения выпуска имеет идентификатор для каждого шага сборки. При создании Release Pipeline идентификаторы должны быть конкретными. Идентификационный номер изменяется после его создания. Итак, когда вы ОБНОВЛЯЕТЕ конвейер выпуска, вы больше не можете использовать «новые» номера идентификаторов этапов (они зарезервированы при первоначальном создании конвейера выпуска), но вместо этого вам нужно использовать теперь действующий ступенчатый идентификатор, который может быть любым.
Антебиос
Итак, фактический процесс должен быть следующим: Для создания процесса используйте шаблон. Для процесса обновления загрузите определение выпуска и сравните его с шаблоном и обновите загруженное определение выпуска, а затем обновите его до VSTS. Ух! Это означает, что мне нужно написать собственный процесс сравнения и проверки ошибок.
Antebios,
Фактически, для определения нового выпуска (POST) вы можете игнорировать idсвойство - idдля объекта def выпуска и для всех environmentобъектов можно игнорировать - установки rankсвойства должно быть достаточно (вместе с другими обязательными) - вызов POST должен автоматически создавать идентификаторы и возвращаются в объекте ответа. После определения релиза создано, чтобы получить все определения в вашем орге вы можете сделать LISTна определениях выпуска - GET вызов документированы здесь
Затемнение
-5

Конвейеры состоят из одного или нескольких заданий и могут включать ресурсы и переменные. Задания состоят из одного или нескольких шагов плюс некоторые данные, относящиеся к заданию. Шаги могут быть задачами, сценариями или ссылками на внешние шаблоны. Это отражено в структуре файла YAML. Пожалуйста, посетите здесь для получения подробной информации

catlight.io -Получение предупреждений
источник
5
Не добавляйте подписи к своим сообщениям; их можно было считать спамом.
Zoe