因此,我正在使用 azure YAML 管道在 Azure 应用服务上部署 Web 应用程序。
我这样做的方式是我创建了 2 个 YAML 管道,一个用于构建,另一个用于发布,其中我为不同的环境设置了多阶段。对于前;开发、测试和生产。
我将它分成两个管道的原因是我的构建管道会产生构建工件,并且通过使用我的发布管道上的 Resouces 部分,我可以选择之前生成的构建(从 UI)并将其部署到我想要的任何阶段到。我的想法是,当我需要部署到其中一个阶段时,我不想每次都构建。我应该能够使用以前生成的工件以及旧的构建工件版本。下面是我的发布管道以及我如何使用资源部分。
发布管道
trigger:
- none
resources:
pipelines:
- pipeline: myappbuild
source: build-test # name of the pipeline that produces an artifact
trigger:
branches:
- master
pool:
vmImage: 'windows-latest'
stages:
- stage: 'DeployToDev'
jobs:
- deployment: Deploy
displayName: Deploy
environment: dev
pool:
vmImage: 'windows-latest'
strategy:
runOnce:
deploy:
steps:
- download: myappbuild
artifact: drop
- task: AzureRmWebAppDeployment@4
displayName: 'Deploy Azure App Service'
inputs:
packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
AppSettings: '-ASPNETCORE_ENVIRONMENT $(EnvironmentName) -ReleaseName $(Release.ReleaseName) -BuildId $(Build.BuildId)'
这运行良好。我能够从 UI 中选择之前的构建,并将该构建部署到发布管道中的任何阶段。
问题:
在发布管道中,很难说出当前在哪个阶段部署了什么。我希望能够根据运行的内容来判断每个环境中的内容。所以在我的例子中,我有 3 个环境,我想知道哪个环境是哪个运行。因为经典 UI 管道有一个发布的概念,它显示哪个工件当前部署在仅 1 个屏幕的位置。在 YAML 中,对于我在“运行”部分下的每个环境,您只能看到 3 个绿点,这并没有说明当前部署在开发阶段的内容。
我可以在一个管道中实现这一目标,而不是创建 2 个管道吗?我可以只有 1 个管道进行构建和发布吗?我知道可以有一个多阶段,其中一个阶段用于构建,其他阶段用于我的发布。但是我怎么才能选择以前的版本部署到任何阶段。因为我不确定我是否可以在这个用例中使用资源部分。想法是我不想一直运行构建。如果这是可以实现的,有人可以指导我更正文档吗?
谢谢。
最佳答案
我会将构建和部署阶段结合在一起,如下所示:
stages:
- stage: Build
jobs:
- job: Build
steps:
- task: YourBuildTask1
inputs:
YourInputsHere: ...
- task: Etc
inputs:
Etc: ...
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: ...
ArtifactName: 'drop'
publishLocation: 'Container'
- stage: DEV
dependsOn: Build
jobs:
- deployment: Deployment
variables:
- template: myDevVariables.template.yml
environment: DEV
strategy:
runOnce:
deploy:
steps:
- task: AzureRmWebAppDeployment@4
displayName: 'Deploy Azure App Service'
inputs:
packageForLinux: '$(Pipeline.Workspace)/**/*.zip'
AppSettings: '-ASPNETCORE_ENVIRONMENT $(EnvironmentName) -ReleaseName $(Release.ReleaseName) -BuildId $(Build.BuildId)'
- stage: Test
dependsOn: DEV
jobs:
- deployment: Deployment
variables:
- template: myTestVariables.template.yml
environment: Test
strategy:
runOnce:
deploy:
steps:
- task: AzureRmWebAppDeployment@4
displayName: 'Deploy Azure App Service'
inputs:
packageForLinux: '$(Pipeline.Workspace)/**/*.zip'
AppSettings: '-ASPNETCORE_ENVIRONMENT $(EnvironmentName) -ReleaseName $(Release.ReleaseName) -BuildId $(Build.BuildId)'
显然没有调试,但我在我自己的管道中成功地做了类似的事情。您使第一个部署阶段依赖于构建,每个后续环境都依赖于前一个。您为每个环境添加批准门以添加手动干预并防止构建立即部署到任何地方。
请注意,在这个例子中,我用 $(Pipeline.Workspace)
替换了 $(System.DefaultWorkingDirectory)
,因为我在 YAML 管道中经常发现$(System.DefaultWorkingDirectory)
对于不同的作业类型具有不同的值。
在下面的示例中,如果我不喜欢 20200105.1 部署的结果,我可以单击它下面的 20201218.1 运行,然后选择要部署到的新环境。
关于azure-devops - Azure yaml 构建和发布管道,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66173835/