Azure DevOps Pipepine с YAML для решения многих проектов

Question

У меня есть решение. NET MVC в Visual Studio 2019, которое содержит 3 проекта:

1. AdminWebApp
2. SharedCode (который установлен как зависимость в обоих другие проекты в VS)
3. FrontWebApp

В Azure DevOps Pipelines Я хочу создавать отдельные сборки для

AdminWebApp

и

FrontWebApp

, которые оба будут содержать

SharedCode

, потому что это содержит помощников et c. Я хочу сделать это с помощью YAML. Должен ли я создать 1 или 2 конвейера (каждый артефакт будет позже опубликован в своей собственной Azure службе приложений)? Какой код YAML для этого?

Answer 1

Вы можете использовать условия для создания отдельных сборок, чтобы вы могли поместить все шаги сборки в один конвейер. Вот похожие топи c.

Простой пример для шагов сборки:

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $files=$(git diff HEAD HEAD~ --name-only)
      $temp=$files -split ' '
      $count=$temp.Length
      For ($i=0; $i -lt $temp.Length; $i++)
      {
        $name=$temp[$i]
        echo "this is $name file"
        if ($name -like "AdminWebApp/*")
          {
            Write-Host "##vso[task.setvariable variable=RunAdminWebApp]True"
          }
        if ($name -like "SharedCode/*")
          {
            Write-Host "##vso[task.setvariable variable=RunSharedCode]True"
          }
        if ($name -like "FrontWebApp/*")
          {
            Write-Host "##vso[task.setvariable variable=RunFrontWebApp]True"
          }
      }
- task: MSBuild@1
  inputs:
    solution: '**/AdminWebApp.csproj'
    msbuildArguments: 'xxx'
  condition: or(variables['RunAdminWebApp'], variables['RunSharedCode'])
- task: MSBuild@1
  inputs:
    solution: '**/FrontWebApp.csproj'
    msbuildArguments: 'xxx'
  condition: or(variables['RunFrontWebApp'], variables['RunSharedCode'])

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

• Если какой-либо файл в вашем проекте AdminWebApp, затем соберите только проекты AdminWebApp и SharedCode. (Первая задача сборки)

• Если какой-либо файл в вашем проекте FrontWebApp изменится, тогда строить только проекты FrontWebApp и SharedCode. (Вторая задача сборки)

• И если файл в SharedCode изменяется, так как два проекта зависят от него, оба будут построены задачи будут выполняться.

Вы должны указать аргументы msbuild (/ t: publi sh ...), чтобы задача сборки могла сгенерировать zip-пакет для развертывания. (В противном случае вам нужно добавить дополнительную задачу для архивирования выходных файлов)

Так как вы получите два опубликованных zip-файла, когда проект SharedCode внесет изменения. Тогда ваш конвейер выпуска должен иметь как минимум две задачи развертывания. Для вашего выпуска: одна задача PS (определить, существует ли A.zip/B.zip, а затем установить пользовательские переменные DeployA / DeployB) и две условные задачи развертывания на основе значения DeployA / DeployB (просто предложение, это не о ваш оригинальный выпуск, поэтому я не буду здесь много говорить об этом ...)

Answer 2

Было бы действительно важно, как выглядит цикл управления и выпуска. Пуристи c может каждый раз все заново развертывать. Реалистичным c способом было бы сгруппировать конвейеры развертывания вместе, когда это имеет смысл.

С точки зрения того, что делать в «способе YAML». Будет смотреть на использование шаблонов YAML

Параметр шаблона будет, по крайней мере, по каталогу проекта для сборки. Это пример шаблона. net Core, но он даст вам представление о мыслительном процессе: например, этот YAML-файл будет называться как-то вроде build-corewebapp.yml

parameters:
  SolutionPath: ''
  BuildConfiguration: 'Release'
  projectName: ''
  DependsOn: []
  publish: 'false'

jobs:
- job: Build_${{ parameters.projectName }}
  dependsOn: ${{ parameters.DependsOn }}
  steps:
  - task: DotNetCoreCLI@2
    displayName: 'dotnet restore'
    inputs:
      command: 'restore'
      projects: '$(Build.SourcesDirectory)/${{ parameters.SolutionPath }}/${{ parameters.projectName }}**/*.csproj'

  - task: DotNetCoreCLI@2
    displayName: 'dotnet build'
    inputs:
      projects: '$(Build.SourcesDirectory)/${{ parameters.SolutionPath }}/${{ parameters.projectName }}**/*.csproj'
      arguments: '--configuration ${{ parameters.BuildConfiguration }}'

  - task: DotNetCoreCLI@2
    displayName: 'dotnet test'
    inputs:
      command: test
      projects: '$(Build.SourcesDirectory)/${{ parameters.SolutionPath }}/${{ parameters.projectName }}.Tests/*.csproj'
      arguments: '--configuration ${{ parameters.BuildConfiguration }} --collect "Code coverage" '
      
- job: Publish_${{ parameters.projectName }}
  dependsOn: Build_${{ parameters.projectName }}
  condition: and(succeeded(),eq( ${{ parameters.publish }}, 'true')) 
  steps:
  - task: DotNetCoreCLI@2
    displayName: 'dotnet publish'
    inputs:
      command: publish
      publishWebProjects: false
      projects: '$(Build.SourcesDirectory)/${{ parameters.SolutionPath }}/${{ parameters.projectName }}**/*.csproj'
      arguments: '--configuration ${{ parameters.BuildConfiguration }} --output $(build.artifactstagingdirectory)'
      zipAfterPublish: True
  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifact: drop'

Шаблон будет вызываться чем-то похожим на:

  jobs:
  - template: build-corewebapp.yml
    parameters:
      projectName: ${{ variables.appProjectName }}
      solutionPath: $(solutionPath)
      publish: 'true'

Для максимального повторного использования я бы рекомендовал любой шаблон сборки существовать в отдельном репозитории, чтобы его можно было использовать в других репозиториях . Это будет настроено в вашем конвейере, ссылаясь на репо, подобное:

resources:
  repositories:
  - repository: repositoryTemplate
    type: git
    name: ProjectName/YAMLTEMPLATERepoName

Профессионал в использовании шаблонов затем обновляет версию задачи или изменение стратегии сборки / развертывания может быть обновлено и ссылаться в одном месте.