Question

因此，我正在使用 azure YAML 管道在 Azure 应用服务上部署一个 Web 应用程序。

我这样做的方式是我创建了 2 个 YAML 管道，一个用于构建，另一个用于发布，其中我为不同环境提供多阶段。例如；开发、测试和生产。

我将它分成两个管道的原因是我的构建管道产生构建工件，通过使用发布管道上的资源部分，我可以选择以前生成的构建（从 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 个 env，我想知道哪个运行是针对哪个 env 的。因为经典 UI 管道有一个发布的概念，它仅在 1 个屏幕中显示当前部署的工件。在 YAML 中，对于我在 Runs 部分下的每个环境，您只能看到 3 个绿点，它没有说明当前在 Dev 阶段部署了什么。
我可以在一个管道内实现这一目标，而不是创建 2 个管道吗？我可以只有 1 个管道来构建和发布吗？我知道有一个多阶段是可能的，我可以有一个阶段进行构建，而其他阶段则用于我的发布。但是我怎么能选择以前的构建来部署到任何阶段。因为我不确定我是否可以在这个用例中使用资源部分。想法是我不想一直运行构建。如果这是可以实现的，有人可以指导我更正文档吗？

谢谢。

Answer 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) 对于不同的作业类型具有不同的值。< /p>

在下面的例子中，如果我不喜欢 20200105.1 部署的结果，我可以点击它下面的 20201218.1 运行，然后选择一个新的环境来部署。

Answer 2

我会把它们结合起来，因为那才是真正的价值所在。将它们分开只会导致移动开销和维护。如果担心 CI/CD YAML 可以通过单个管道提供支持，并在部署阶段周围设置条件以使用 - ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/master')}} :

检查分支

有关环境可见性的问题，请单击 Azure DevOps 中的“环境”按钮，因为它会显示在项目内的所有存储库中命中该环境的所有作业。

最佳实践是为每次提交到 master 创建一张 CD。这将为所有环境创建一个版本并部署到 DEV。从而为每个构建保留一个版本。

Azure yaml 构建和发布管道

2 个答案: