我的 YAML 管道有 3 个部署阶段:
Alpha servers -> Beta servers -> Production servers
我有 3 个分支机构。一种用于 alpha 代码,一种用于 beta 代码,一种用于生产。我想要实现的是在 YAML 中自动化以下工作流程(我已经为 alpha 分支设置了触发器,但这是关于后期阶段的问题):
Changes merged to the alpha branch after a pull request is completed -> alpha branch code build -> deployment to alpha servers -> *manual testing performed on alpha servers* -> only these specific changes merged from alpha to beta branch -> beta branch code build -> deployment to beta servers -> *manual testing performed on beta servers* -> only these specific changes merged from beta to main branch -> main branch code build -> deployment to production servers
当更改合并到测试版和主分支时,我不知道如何使测试版和生产阶段运行。如果我为所有 3 个分支(alpha、beta、main)声明触发器,它每次都会创建一个新的管道运行,而不是进行 1 次特定更改的运行:
alpha(run after merge to alpha branch) -> beta(run after merge to beta branch) -> prod(run after merge to main branch)
我正在使用 alpha、beta、prod 部署的条件来检查哪个分支已合并到,但最终运行了 3 次:
alpha(run after merge to alpha branch) -> beta(did not run) -> prod(did not run)
alpha(did not run) -> beta(run after merge to beta branch) -> prod(did not run)
alpha(did not run) -> beta(did not run) -> prod(run after merge to main branch)
我的管道:
variables:
- name: app_name
value: 'myapp'
trigger:
batch: true
branches:
include:
- alpha
- beta
stages:
- stage: buildAlpha
condition: and(eq(variables['Build.Reason'], 'IndividualCI'), eq(variables['Build.SourceBranch'], 'refs/heads/alpha'))
pool:
vmImage: windows-2022
jobs:
- job: compile
steps:
- checkout: git://MyTeam/MyProjectTest@alpha
- task: UseDotNet@2
displayName: 'Use .NET Core 3.1'
inputs:
packageType: 'sdk'
version: '3.1.x'
- task: NuGetToolInstaller@0
displayName: 'Use NuGet 6.0.0'
inputs:
versionSpec: 6.0.0
- task: NuGetCommand@2
displayName: 'NuGet restore'
inputs:
restoreSolution: 'MyProject\MyProject.sln'
- task: DotNetCoreCLI@2
inputs:
command: 'publish'
publishWebProjects: false
projects: 'MyProject\MyProject.sln'
arguments: '-o $(build.artifactstagingdirectory)'
modifyOutputPath: false
zipAfterPublish: true
- publish: '$(build.artifactstagingdirectory)'
artifact: drop
- stage: deployDev
condition: and(eq(variables['Build.Reason'], 'IndividualCI'), eq(variables['Build.SourceBranch'], 'refs/heads/alpha'))
jobs:
- deployment: deployToAlpha
variables:
- group: DevVariables
environment:
name: dev
resourceType: VirtualMachine
tags: web
strategy:
runOnce:
deploy:
steps:
- task: IISWebAppDeploymentOnMachineGroup@0
displayName: 'IIS Web App Deploy'
inputs:
WebSiteName: 'myapp.og.com'
VirtualApplication: $(app_name)
RemoveAdditionalFilesFlag: true
TakeAppOfflineFlag: True
XmlVariableSubstitution: True
Package: '$(Pipeline.Workspace)/drop/**/*.zip'
- task: qetza.replacetokens.replacetokens-task.replacetokens@4
displayName: 'Replace tokens in **/appsettings.json'
inputs:
targetFiles: 'F:/Websites/myapp.og.com/$(app_name)/appsettings.json'
actionOnMissing: fail
keepToken: true
actionOnNoFiles: fail
enableTelemetry: false
- stage: buildBeta
condition: and(eq(variables['Build.Reason'], 'IndividualCI'), eq(variables['Build.SourceBranch'], 'refs/heads/beta'))
pool:
vmImage: windows-2022
jobs:
- job: compile
steps:
- checkout: git://MyTeam/MyProjectTest@beta
- task: UseDotNet@2
displayName: 'Use .NET Core 3.1'
inputs:
packageType: 'sdk'
version: '3.1.x'
- task: NuGetToolInstaller@0
displayName: 'Use NuGet 6.0.0'
inputs:
versionSpec: 6.0.0
- task: NuGetCommand@2
displayName: 'NuGet restore'
inputs:
restoreSolution: 'MyProject\MyProject.sln'
- task: DotNetCoreCLI@2
inputs:
command: 'publish'
publishWebProjects: false
projects: 'MyProject\MyProject.sln'
arguments: '-o $(build.artifactstagingdirectory)'
modifyOutputPath: false
zipAfterPublish: true
- publish: '$(build.artifactstagingdirectory)'
artifact: drop
- stage: deployBeta
condition: and(eq(variables['Build.Reason'], 'IndividualCI'), eq(variables['Build.SourceBranch'], 'refs/heads/beta'))
jobs:
- deployment: deployToBeta
variables:
- group: betavariables
environment:
name: beta
resourceType: VirtualMachine
tags: web
strategy:
runOnce:
deploy:
steps:
- task: IISWebAppDeploymentOnMachineGroup@0
displayName: 'IIS Web App Deploy'
inputs:
WebSiteName: 'myapp.og.com'
VirtualApplication: $(app_name)
RemoveAdditionalFilesFlag: true
TakeAppOfflineFlag: True
XmlVariableSubstitution: True
Package: '$(Pipeline.Workspace)/drop/**/*.zip'
- task: qetza.replacetokens.replacetokens-task.replacetokens@4
displayName: 'Replace tokens in **/appsettings.json'
inputs:
targetFiles: 'F:/Websites/myapp.og.com/$(app_name)/appsettings.json'
actionOnMissing: fail
keepToken: true
actionOnNoFiles: fail
enableTelemetry: false
最佳答案
在您的场景中,三个分支中的拉取请求合并会触发三个管道运行。这是预期的行为。
在Yaml Pipeline中,触发器只能在根级别设置。它适用于整个管道。所以三个 PR 合并会触发三个 pipeline 运行,并且它们是独立的。
当 PR merge 触发 pipeline 时,会根据条件运行匹配阶段。
变量将使用相同的值进行评估,因此某些阶段将运行,而其他阶段将跳过。
对于您的要求:三个 PR 合并触发同一管道运行的不同阶段,恐怕没有现成的方法可以满足您的要求。
解决方法是,您可以根据阶段拆分为三个管道,并为每个管道设置相应的触发器。
我建议您可以创建a suggestion feedback报告功能要求。
关于azure - 当指定分支的拉取请求完成时触发下一个管道阶段,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/72729464/