Как выполнить развертывание в разных средах в зависимости от ветки в Azure DevOps?

Question

Я хотел бы, чтобы в Azure DevOps был реализован следующий конвейер:

• Один Build этап, на котором создается основной артефакт
• 3 этапа развертывания для Dev Preprod и Prod, которые развернут артефакт, созданный на предыдущем этапе, в соответствующих средах

Я могу сделать это с помощью Azure DevOps Multistage Pipelines и conditions в названии филиала. Однако, когда я сначала делаю sh ветку dev, и она успешно строится, а затем я sh говорю preprod ветку как перемотку вперед , я бы ожидал, что конвейер будет повторно использовать уже созданные артефакты из этапа Build, запущенного в ветке dev, потому что это одни и те же коммиты.

В DevOps я наблюдаю, что этап Build повторно запускается даже для того же совершить, когда я sh в каждую отдельную ветку. Можно ли достичь того, что я пытаюсь сделать, используя конвейеры на основе YAML?

Edit

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

Answer 1

Возможно ли достичь того, что я пытаюсь сделать, используя конвейеры на основе YAML? Конвейеры на основе YAML .

Для этого мы должны убедиться, что каждая фиксация в ветке Preprod такая же, как и каждая фиксация в ветке dev, прежде чем мы сможем использовать условия в имени ветки, чтобы пропустить этап сборки

stages:
-stage: Build
   displayName: Build
   and(succeeded(), eq(variables['CommitBranchName'], 'refs/heads/dev'))

Тогда мы могли бы получить CommitBranchName командой git git branch --contains .

Однако мы не можем гарантировать, что каждая ветвь является то же, что и коммит разработчика, и azure DevOps не может определить, совпадают ли эти два коммита. Событие, вызвавшее сборку, - это фиксация, а не содержимое фиксации.

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

Answer 2

Это должен быть скорее комментарий (поскольку это скорее идея, чем реальное рабочее решение), чем ответ, но я боюсь, что я увеличу лимит.

На мой взгляд, это невозможно, но позвольте мне объясните это подробно. Потому что вам действительно нужен контроллер конвейера с потоком фиксации. Что вам нужно, так это ворота / подтверждение на основе появления фиксации в определенной ветке. Такое одобрение возможно.

Представьте, что вы сделали фиксацию в ветке Dev. Ваш конвейер запускается, развертывание в среде Dev завершается, и время для Preprod не наступает, но перед этим выполняется утверждение с вызовом функции Azure. Вы передадите эти заголовки

{
"Content-Type":"application/json", 
"PlanUrl": "$(system.CollectionUri)", 
"ProjectId": "$(system.TeamProjectId)", 
"HubName": "$(system.HostType)", 
"PlanId": "$(system.PlanId)", 
"JobId": "$(system.JobId)", 
"TimelineId": "$(system.TimelineId)", 
"TaskInstanceId": "$(system.TaskInstanceId)", 
"AuthToken": "$(system.AccessToken)",
"BuildId":"$(Build.BuildId)",
"StageName":"$(System.StageName)"
}

В Azure Function вы получите идентификатор сборки и имя стадии. С идентификатором сборки вы можете вызвать REST API, чтобы получить изменения и проверить, уже ли они находятся в ветке stageName (в данном случае это Preprod. Поскольку их там нет, этап завершится ошибкой.

После перемещения эту фиксацию в ветке PreProd вы должны запустить ранее неудачную сборку, чтобы снова проверить условие и забрать уже созданный артефакт. Вероятно, вам нужно сделать какой-то веб-крючок, и, что еще хуже, это невозможно в настоящий момент. конкретный этап c (проверьте документацию ). Вы можете попытаться получить сборку с ошибкой этапа и снова поставить их в очередь, но в этом случае вы снова выполните развертывание на Dev.

Итак, вы видите, что этого чрезвычайно сложно достичь. Но, возможно, кто-то придет к лучшему.