3

因此，我正在使用 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 中选择以前的构建，并将该构建部署到我发布管道中的任何阶段。

问题：

  1. 在发布管道中，很难说当前在什么阶段部署了什么。我希望能够根据运行的内容来判断每个环境中的内容。所以就我而言，我有 3 个环境，我希望能够分辨出哪个运行是针对哪个环境的。因为经典 UI 管道有一个发布概念，它显示当前部署的工件仅在 1 个屏幕中。其中 YAML 对于我在 Runs 部分下的每个环境，您只能看到 3 个绿点，这并不能说明 Dev 阶段当前部署的内容。

  2. 我可以在一个管道中实现这一点，而不是创建 2 个管道吗？我可以只有 1 个管道来构建和发布吗？我知道可以有一个多阶段，我可以有一个阶段用于构建，而其他阶段用于我的发布。但是我如何能够选择以前的构建部署到任何阶段。因为我不确定我是否可以在这个用例中使用资源部分。想法是我不想一直运行构建。如果这是可以实现的，有人可以指导我更正文件吗？

谢谢你。

4

2 回答 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 运行，然后选择要部署到的新环境。

示例运行列表

于 2021-02-12T14:58:03.277 回答
0

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

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

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

于 2021-02-12T15:08:58.877 回答