Выполнять этап в конвейере DevOps Release каждую ночь в планировщике

Question

У меня есть конвейер Azure DevOps CI Build and Release со следующей настройкой:

• CI Build запускается с каждым новым коммитом в develop ветви и создает Build Drop (Artifact)
• Выпуск конвейера запускается с каждым новым Артефактом и развертывается в INT и, в конечном итоге, в PROD (после ручного одобрения)

Я хотел бы добавить 3-й этап (называемый, например, MONITOR) который запускается после выпуска PROD каждую ночь , используя то же падение, что и используемый этап PROD, со следующей схемой:

[Build Drop] -> [INT] -> manual approval: [PROD] -> nightly scheduler: [MONITOR]

Это представляется невозможным я, вы знаете, как достичь этой цели?

Для меня крайне важно следующее:

• МОНИТОР и PROD всегда запускаются из одного и того же артефакта
• МОНИТОР выполняется, только если PROD был успешным
• , если есть более новая версия PROD, старый МОНИТОР больше не выполняется, и вместо этого самый новый выполняется с использованием новейшего Артефакта, который сделал его PROD

До сих пор я пытался сделать следующее:

• объединить develop в master, когда коммит добрался до PROD. А затем использовал запланированную ночную сборку из master со стадией MONITOR - это работает, но MONITOR использует артефакт, отличный от PROD, поэтому я не могу его использовать
• использовал запланированный триггер для MONITOR после PROD - не работает, MONITOR выполняется только один раз в запланированное время и никогда больше
• создал дополнительный конвейер выпуска на основе специфика c версия артефакта с запланированным триггером - это работает, но я должен поддерживать спецификацию c Версия Артефакта вручную с каждым успешным выпуском PROD. Еще одно предостережение: мне нужно использовать 2 отдельных конвейера, что делает обзор не таким приятным. (но пока лучшее решение, которое я достиг)

У вас есть лучшие идеи? большое спасибо

Answer 1

То, что я хотел бы сделать, это иметь 2 отдельных конвейера выпуска.

Это позволяет планировать выпуск без создания нового артефакта (запланированная сборка).

Затем я сделаю кое-что из того, что @ Soccerjoshj07 предложил, чтобы я вызывал REST API в задаче на конвейере / этапе MONITOR.

Я бы сделал вызов API REST для конечной точки Releases , чтобы получить релизы top=1 для releasedefinitionid=x. Затем используйте конечную точку Release Environment , чтобы получить среду PROD для этого последнего идентификатора выпуска. С окружающей средой в руках, проверьте статус для succeeded. Если нет, откажитесь от выпуска.

Отредактируйте в соответствии с новым требованием, изложенным в комментарии

Учитывая PROD.1 - успешно и PROD.2 - ошибка когда срабатывает MONITOR, то для MONITOR следует использовать артефакт из PROD.1.

С этим критерием я бы изменил некоторые вещи. Вместо того, чтобы копать MONITOR go для последней версии PROD и терпеть неудачу, если последняя не удалась, я бы сделал успешный PROD stage tag тегом своего артефакта сборки и задействовал фильтры артефактов в конвейере Monitor.

Пометка может производиться с помощью REST api или с помощью задачи построения или выпуска тегов из Инструменты Colin для сборки и выпуска ALM Corner и может выглядеть так:

Answer 2

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

В качестве обходного пути вы можете добавить пользовательское условие для задания MONITOR stage.

Например, в yaml:

- stage: MONITOR
   jobs:      
   - job:
     condition: and(always(), eq(variables['Release.Reason'], 'Schedule'))
     steps:

В пользовательском интерфейсе вы можно установить это в Run this job агентского задания:

В этом случае этап выполняется только тогда, когда разблокирование инициируется по запланированному триггеру. Если выпуск инициирован по другим причинам, этап MONITOR будет пропущен.

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

Или напишите скрипт с задачей powershell (на этапах INT / PROD), чтобы определить, является ли Release.Reason Schedule. Если да, пропустите текущий этап.

Чтобы получить последнюю версию артефакта PROD и определить состояние развертывания PROD, вы можете обратиться к двум ответам выше.

Answer 3

Используете ли вы шаблон YAML и играли ли вы с расписанием cron? https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled -triggers

При использовании classi c Release UI, я думаю, вы можете иметь триггер определения по расписанию, но это поставит в очередь все определение. Возможно, вам придется проявить творческий подход к переменным и, возможно, создать «isScheduled = true» и использовать его, чтобы определить, следует ли пропустить задачи.

Другие идеи: создать приложение logi c или приложение-функцию, которое вызывает REST API? Пример приложения и ссылка на github здесь: https://oshamrai.wordpress.com/2019/04/22/azure-devops-rest-api-19-queue-builds-and-download-build-results/

Расширение CLI Azure -Devops может быть проще, хотя: https://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines/build?view=azure-cli-latest#ext - azure -devops- Az-трубопроводы-строительство-очереди