Azure Pipelines yml帮助-了解我的yml文件及其未部署的原因

Question

我真的是Azure DevOps的新手，正在尝试为我的项目配置Azure管道。

当前我的.yml文件看起来像这样：

trigger:
- my-test-branch

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

- task: DotNetCoreCLI@2
  displayName: 'dotnet test $(buildConfiguration)'
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  displayName: 'dotnet publish $(buildConfiguration)'
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishBuildArtifacts@1
  displayName: 'publish artifacts'
  inputs: 
    pathtoPublish: '$(build.artifactstagingdirectory)'

我设法从各种来源收集了这些信息，现在可以成功构建管道，因为它可以构建我的项目，运行NUnit测试，并基于此通过或失败。我对此有一些疑问：

1. PublishBuildArtifacts任务是做什么的？我以为文件的这一部分是连续交付的部分，会自动将代码发布到我的Web应用程序中，但是这似乎没有发生，并且我意识到我不太了解“发布构建工件”的含义- Azure文档中的解释对我来说也没有太多启发。

2. 从1.开始，如何配置连续传送？我有一个Web应用程序，希望我的代码在测试通过后自动部署到那里。

3. trigger分支的作用是什么？为了澄清，我将解释我的项目的结构：我有master分支，develop分支（分支为主）和my-test-branch分支开发。如果我希望代码从develop自动部署到my-test-branch（如果所有测试均通过），是否可以配置它？还是必须作为请求请求完成？

Answer 1

PublishBuildArtifacts任务只是将您在构建中创建的任何工件发布为构建的工件。这仅意味着它们在构建信息的工件选项卡中可用，并且其他构建或发行版可以根据需要使用这些工件，与释放到Azure无关。

如果要进行连续交付，那么您要开始考虑创建一个使用构建输出并将其推送到Azure（或您想去的其他地方）的发行版。您可以查看使用multi-stage YAML pipelines在YAML中创建预览版本，也可以查看较早的视觉效果release pipelines。

您列出的触发器意味着对该分支的任何提交都会导致该管道运行，但是对master或development的任何提交都不会。