Azure yaml 构建和发布管道

Question

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

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

我将其分为两个管道的原因是我的构建管道会产生构建工件，并且通过使用我的发布管道上的 Resouces 部分，我可以 select 之前生成的构建（来自 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 个环境，我想知道哪个运行是哪个环境。因为 Classic UI 管道有一个发布的概念，它显示哪个工件当前部署在仅 1 个屏幕的位置。其中 YAML 对于我在“运行”部分下的每个环境，您只能看到 3 个绿点，这并没有说明当前部署在开发阶段的内容。
我可以在一个管道中实现这一点，而不是创建 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) 对于不同的作业类型有不同的值.

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

Answer 2

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

检查分支

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

最佳做法是为每次提交到 master 中创建一张 CD。这将为所有环境创建一个版本并部署到 DEV。因此，为每个构建保留一个版本。

Azure yaml 构建和发布管道

Azure yaml build and release pipeline

azure-devops

azure-yaml-pipelines