Мой файл YAML в моих репозиториях позволил выполнить автоматическое развертывание для моих сред разработки и контроля качества. Но для Прода это, похоже, не работает, несмотря на выполнение условий.
name: $(BuildDefinitionName)-$(SourceBranchName)-$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
trigger:
branches:
include:
- main
- release/*
paths:
include:
- workflows/*
- ProductXETL/*
parameters:
- name: deployCluster
type: boolean
default: false
variables:
tag: '$(Build.BuildId)'
workingDirectory: '$(System.DefaultWorkingDirectory)'
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
stages:
- stage: Build
displayName: "Build"
jobs:
- job: Build
displayName: Build
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
steps:
- task: CopyFiles@2
displayName: Copy ARM templates to staging
inputs:
SourceFolder: deploy
TargetFolder: $(Build.ArtifactStagingDirectory)
- task: CopyFiles@2
displayName: Copy workflows to staging
inputs:
SourceFolder: workflows
TargetFolder: $(Build.ArtifactStagingDirectory)/workflows
- task: CopyFiles@2
displayName: Copy pyjaws to staging
inputs:
SourceFolder: pyjaws
TargetFolder: $(Build.ArtifactStagingDirectory)/pyjaws
- task: PublishPipelineArtifact@1
displayName: 'Publish Pipeline Artifact: drop'
inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'
artifact: deploy
- stage: Dev
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
dependsOn: ["Build"]
displayName: "Deploy to Dev"
variables:
- group: PX DataPlatform Release (Dev)
jobs:
- deployment:
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
displayName: "Deploy to Dev"
environment: Dev
strategy:
runOnce:
deploy:
steps:
- template: azure-pipeline.template.yml
parameters:
serviceConnection: 'Company Analytics Dev UK'
subscriptionId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
deployCluster: ${{ parameters.deployCluster }}
environment_name: DEV
- stage: QA
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
dependsOn: ["Dev"]
displayName: "Deploy to QA"
variables:
- group: PX DataPlatform Release (QA)
jobs:
- deployment:
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
displayName: "Deploy to QA"
environment: QA
strategy:
runOnce:
deploy:
steps:
- template: azure-pipeline.template.yml
parameters:
serviceConnection: 'Company Analytics Dev UK'
subscriptionId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
deployCluster: ${{ parameters.deployCluster }}
environment_name: QA
- stage: Prod
condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/heads/release/'))
dependsOn: ["Build"]
displayName: "Deploy to Prod"
variables:
- group: PF DataPlatform Release (Prod)
jobs:
- deployment:
pool:
name: Company Analytics SelfHosted Prod
demands:
- agent.name -equals px-dataplat-vm2
displayName: "Deploy to Prod"
environment: UK Production
strategy:
runOnce:
deploy:
steps:
- template: azure-pipeline.template.yml
parameters:
serviceConnection: 'Company Analytics Prod UK'
subscriptionId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
deployCluster: ${{ parameters.deployCluster }}
environment_name: PROD
Теоретически, когда я создаю новую ветку, начинающуюся с «release/», я ожидаю, что она начнет создаваться, и я смогу взять ее оттуда, но вообще ничего не запускается, что контрастирует с моим развертыванием разработки. Мое развертывание для разработчиков работает хорошо: как только я завершаю PR в своей основной ветке, там начинается развертывание, и все работает нормально.
Я подумал, может быть сюда добавить второго агента:
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
поскольку мой Dev/QA использует один и тот же агент, а Prod использует другой агент, но даже после того, как он был указан под моим агентом разработки, тоже не повезло. Я также пробовал использовать
-or:
и перечислил обоих агентов ниже, тоже не повезло.
Там, где это возможно, я анонимизировал части своего кода, надеюсь, это имеет смысл.
Если кто-то может помочь мне понять, почему мое развертывание продукта не запускается автоматически, я был бы признателен.
Спасибо.
@RuiJarimba Просто разговариваю с моей командой, и хотя кажется, что это дополнительный коммит, в котором я что-то меняю в этой папке, они больше заинтересованы в том, чтобы конвейер разработки запускался, как только я создаю ветку выпуска, но да, теоретически вы правильный. Изменение этих папок приведет к запуску конвейера.
Обновил свой ответ. Я не тестировал код, но в любом случае его будет достаточно легко понять и изменить в соответствии с вашими потребностями.
Тестирую ваш файл yaml в своем конвейере, он работает нормально. Проблема не связана с состоянием на вашей prod
стадии.
Пожалуйста, проверьте, находится ли файл yaml, используемый для запуска этого конвейера, в вашей ветке release/*
. Если нет, добавьте, пожалуйста, в release/*
ветки.
Теоретически, когда я создаю новую ветку, начинающуюся с «release/», я ожидаю, что она начнет создавать
В соответствии с вашим фильтром пути в триггере конвейер будет запускаться только при наличии изменений в workflows/*
и ProductXETL/*
. Создание новой ветки на основе «main» не приведет к запуску конвейера, поскольку в этих путях нет изменений.
развертывание было немедленно запущено, когда вы создали новую ветку «release/»?
TL;DR ваша сборка будет запущена тогда и только тогда, когда есть изменения в любой из папок, указанных в разделе path
, при использовании ветвей main
или release/*
.
Я провел несколько тестов, используя сборку с аналогичным триггером, содержащим путей:
trigger:
branches:
include:
- main
- release/*
paths:
include:
- workflows/*
- ProductXETL/*
Теоретически, когда я создаю новую ветку, начинающуюся с
release/
, я ожидаю, что она начнет создаваться.
Сборка не будет запущена сразу после создания ветки, поскольку в папках workflows/
или ProductXETL/
нет изменений. Если вы измените файлы в любой из этих папок ПОСЛЕ создания ветки, сборка будет запущена.
Мое развертывание для разработчиков работает хорошо: как только я завершаю PR в своей основной ветке, там начинается развертывание, и все работает нормально.
Сборка будет запущена только в том случае, если ваш запрос на включение содержит изменения в папках workflows/
или ProductXETL/
.
Если path
имеет смысл для сред Dev
и QA
, но не для Prod
, я бы предложил вам создать 2 отдельных конвейера, каждый со своим триггером.
Использование базового конвейера (через расширяет шаблоны) решит проблему дублирования кода.
Конвейер для сред разработки и контроля качества:
parameters:
- name: deployCluster
type: boolean
default: false
trigger:
branches:
include:
- main
paths:
include:
- workflows/*
- ProductXETL/*
extends:
template: base-pipeline.yaml
parameters:
isProduction: false
deployCluster: ${{ parameters.deployCluster }}
Конвейер для среды Prod:
parameters:
- name: deployCluster
type: boolean
default: false
trigger:
branches:
include:
- release/*
extends:
template: base-pipeline.yaml
parameters:
isProduction: true
deployCluster: ${{ parameters.deployCluster }}
Базовый трубопровод:
# base-pipeline.yaml
parameters:
- name: isProduction
displayName: A boolean value to determine if the pipeline is for production
type: boolean
- name: deployCluster
type: boolean
default: false
variables:
tag: '$(Build.BuildId)'
workingDirectory: '$(System.DefaultWorkingDirectory)'
pool:
name: Company Analytics SelfHosted
demands:
- agent.name -equals px-dataagent-de
stages:
- stage: Build
displayName: "Build"
# ...
- ${{ if eq(parameters.isProduction, false) }}:
- stage: Dev
dependsOn: ["Build"]
displayName: "Deploy to Dev"
# ...
- stage: QA
dependsOn: ["Dev"]
displayName: "Deploy to QA"
# ....
- ${{ if eq(parameters.isProduction, true) }}:
- stage: Prod
dependsOn: ["Build"]
displayName: "Deploy to Prod"
# ...
Примечание:
Build.SourceBranch
, больше не нужны. Вместо этого используется шаблонное выражение, основанное на параметре isProduction
.В любом случае я могу немедленно запустить конвейер при создании новой ветки с префиксом «release/»?
@codingnoob обновил мой ответ.
Цените это, еще предстоит протестировать, но я думаю, что вы попали в самую точку, я проверю это в свое время. ваше здоровье.
Что произойдет, если вы закомментируете раздел
paths
вашего триггера? Или, как вариант, создать веткуrelease/xxx
и потом что-то изменить внутри папокworkflows
илиProductXETL
?