У нас есть два конвейера сборки, которые строятся из двух разных путей в одном и том же хранилище.
BuildPipelineA строит / PathA из AppRepo и публикуетартефакт АртефактА
BuildPipelineB строит / PathB из AppRepo и публикует артефакт ArtifactB
Затем у нас есть конвейер выпуска, который использует оба этих артефакта для развертывания приложения в некоторых веб-приложениях.
В качестве стратегии ветвления мы используем собственный рабочий процесс Gitflow. Единственное отличие состоит в том, что у нас есть две команды разработчиков, каждая из которых имеет собственную ветку интеграции. Поэтому вместо классической ветви develop мы получаем develop, develop-teamAlpha и develop-teamBeta. Триггеры настроены на все три ветви, в дополнение к master, release/ и hotfix/, так что это всего шесть целевых ветвей.
Я пытаюсь достичьиметь процесс CI / CD, который всегда будет принимать артефакты из соответствующей (той же самой) ветви для автоматически запускаемого создания выпуска.
Например, с учетом предыдущего master ArtifactB существует:
Разработчик фиксирует изменения master для некоторых файлов в / PathA
BuildPipelineA вызывает и строит ArtifactA из master
ReleasePipeline теперь должен создать новый выпуск с использованием masterАртефактА и master АртефактВ
Я хочу, чтобы происходило то же самое, даже если инициирующий артефакт происходит из другой ветви:
Разработчик фиксирует изменения develop для некоторых файлов в / PathB
BuildPipelineB вызывает и строит АртефактB из develop
ReleasePipeline должен теперьсоздать новый выпуск, используя develop ArtifactB и (существующий) develop ArtifactA
Попробуйте 1: Итак, первое, что я попробовал, было использовать $ (Release.Artifacts.ArtifactA.SourceBranch) в качестве исходной ветви для ArtifactB : Release.Artifacts. Пример webapp.SourceBranch
Это не работает, поскольку эта переменная зависит от выпуска, для которого уже выбраны ее артефакты.
Try 2: Моя вторая попытка состояла в том, чтобы создать новый конвейер, который бы объединял два артефакта, при этом удостоверившись, что они являются последними из определенной, соответствующей ветви.
Эта сборка будет вызвана завершением любого из BuildPipelineA или BuildPipelineB . Я использовал некоторые вызовы API, чтобы получить исходную ветвь запускающей сборки, и использовал это для загрузки ArtifactA и ArtifactB из соответствующей ветви, а затем опубликовал новую, объединенную, ArtifactC .
Поскольку исходный репозиторий для этого "объединяющего конвейера" не имеет значения, я решил использовать второй репозиторий, где я хранил свои сценарии, которые я использовал для вызовов API.
Теперь, делая это, я не контролирую ветвь, используемую для создания новой версии из ArtifactC (объединенный артефакт), потому что источники этого артефакта всегда поступают из master второго репозитория. ветка. Это также заставляет меня потерять всю отслеживаемость, предлагаемую DevOps Azure. Следующий пример может прояснить ситуацию: ArtifactC
Кроме того, он вообще не интегрируется с настройкой фильтрации артефактов, которую мы используем для каждой отдельной среды.
Я очень открыт для любых предложений.