为ASP.NET Core Web App制作更简洁，更有目的的azure-pipelines.yml

A few months back I moved my CI/CD (Continuous Integration/Continuous Development) to Azure DevOps for free. You get 1800 build minutes a month FREE and I'm not even close to using it with three occasionally-updated sites building on it.

几个月前，我免费将CI / CD(连续集成/连续开发)迁移到Azure DevOps 。 您每月可以免费获得1800个构建分钟，并且我甚至无法将其与三个偶尔更新的站点一起使用。

It wasn't too hard, but as with all build pipelines you'll end up with a bunch of trial and error builds until you really get it dialed in.

这并不难，但是与所有构建管道一样，您将最终经过一堆试错法构建，直到您真正拨通它。

I was working/pairing with Damian today because I wanted to get my git commit hashes and build ids embedded into the actual website so I could see exactly what commit is in production. How to do that will be the next post!

我今天与Damian合作/配对是因为我想获取git commit哈希并将构建的id嵌入到实际网站中，以便我可以确切地看到生产中的提交。 下一篇文章将如何做！

However, while tidying up we noticed some possible speed up and potential issues with my original azurepipeslines.yml file, so here's my new one!

但是，在整理时，我们发现原始的azurepipeslines.yml文件可能会加快速度并存在潜在的问题，所以这是我的新文件！

NOTE: There's MANY ways to write one of these. For example, note that I'm allowing the "dotnet restore" to happen automatically as a sign effect of the call to dotnet build. Damian prefers to make that more explicit as its own task so he can see timing info for it. It's up to you, just know the side effects and measure!

注意：有许多方法可以编写其中一种。 例如，请注意，我允许“ dotnet恢复”自动发生，这是对dotnet build的调用的标志作用。 达米安(Damian)希望将其明确化为自己的任务，以便他可以查看其时序信息。 由您决定，只知道副作用和措施！

Let's read the YAML and see what's up here.

让我们阅读YAML，看看这里有什么。

• My primary Git branch is called "main" so my Pipeline triggers on commits to main.

  我的主要Git分支称为“ main”，因此我的Pipeline在对main的提交时触发。

• I'm using a VM from the pool that's the latest Ubuntu.
  我正在使用最新Ubuntu池中的VM。
• I'm doing a Release (not Debug) build and putting that value in a variable that I can use later in the pipeline.
  我正在做一个Release(不是Debug)构建，并将该值放在一个变量中，以便以后在管道中使用。
• I'm using a "runtime id" of linux-x64 and I'm storing that value also for use later. That's the .NET Core runtime I'm interested in.
  我正在使用linux-x64的“运行时ID”，并且存储了该值以供以后使用。 那就是我感兴趣的.NET Core运行时。
• I'm passing in the -r $(rid) to be absolutely clear about my intent at every step.
  我传递-r $(rid)是为了明确我在每个步骤中的意图。
• I want to build ONCE so I'm using --no-build on the publish command. It's likely not needed, but because I was using a rid on the build and then not using it later, my publish was wasting time by building again.
  我想构建一次，所以我在发布命令上使用了--no-build。 可能不需要，但是因为我在构建上使用了一次摆脱，然后又不使用它，所以我的发布浪费了时间，再次构建。
• The dotnet test command uses -r for results (dumb) so I have to pass in --runtime if I want to pass in a rid. Again, likely not needed, but it's explicit.
  dotnet测试命令使用-r表示结果(哑)，因此如果要传递rid，则必须传递--runtime。 同样，可能不需要，但这是明确的。
• I publish and name the artifact (fancy word for the resulting ZIP file) so it can be used later in the Deployment pipeline.
  我发布并命名了工件(为生成的ZIP文件添加了奇特的词)，以便稍后可以在Deployment管道中使用它。

Here's the YAML

这是YAML

# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'
  rid: 'linux-x64'

steps:
    - task: UseDotNet@2
      inputs:
        version: '3.1.x'
        packageType: sdk
      
    - task: DotNetCoreCLI@2
      displayName: 'dotnet build $(buildConfiguration)'
      inputs:
        command: 'build'
        arguments: '-r $(rid) --configuration $(buildConfiguration) /p:SourceRevisionId=$(Build.SourceVersion)'

    - task: DotNetCoreCLI@2
      displayName: "Test"
      inputs:
        command: test
        projects: '**/*tests/*.csproj'
        arguments: '--runtime $(rid) --configuration $(buildConfiguration)'

    - task: DotNetCoreCLI@2
      displayName: "Publish"
      inputs:
        command: 'publish'
        publishWebProjects: true
        arguments: '-r $(rid) --no-build --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
        zipAfterPublish: true

    - task: PublishBuildArtifacts@1
      displayName: "Upload Artifacts"
      inputs:
        pathtoPublish: '$(Build.ArtifactStagingDirectory)' 
        artifactName: 'hanselminutes'

Did I miss anything? What are your best tips for a clean YAML file that you can use to build and deploy a .NET Web app?

我有想念吗？ 您可以使用干净的YAML文件来构建和部署.NET Web应用的最佳秘诀是什么？

翻译自: https://www.hanselman.com/blog/making-a-cleaner-and-more-intentional-azurepipelinesyml-for-an-aspnet-core-web-app