Предыдущий

Следующая

Упражнение. Использование шаблонов для сборки нескольких конфигураций

Завершено

В предыдущих упражнениях вы реализовали конвейер, который создает веб-сайт Space Game. Вы начали со скрипта, который выполнял каждое действие сборки, и сопоставили каждое действие с соответствующей задачей конвейера. Выходными данными конвейера является ZIP-файл, содержащий скомпилированное веб-приложение.

В этом упражнении вы используете шаблон для определения задач сборки, которые могут создать любую конфигурацию, определенную в файле проекта. Шаблоны позволяют определять логику один раз, а затем многократно использовать ее. Шаблоны объединяют содержимое нескольких файлов YAML в один конвейер.

Давайте узнаем, как дела у Мары и Амиты.

Демоверсия

Маре не терпится поделиться результатами. Она находит Амиту, чтобы показать свой конвейер сборки.

Амита: Удивительно, что ты проделала столько работы так быстро! Я как раз хотела с тобой поговорить, потому что получила письмо о том, что сборка готова. Спасибо! Я вижу, что конвейер собирает только конфигурацию выпуска. У нас есть сборки отладки, чтобы собирать дополнительную информацию при сбое приложения. Это можно добавить?

Мара: Конечно. Я забыла про отладочные сборки во время настройки. Давай добавим их вместе?

Амита: Ты показала мне файл YAML, который определяет шаги сборки, но я не уверена, что знаю, как его изменить.

Мара: Хорошо. Смотри, как я работаю. Обдумаем все вместе.

Как определить обе конфигурации сборки?

Рассмотрите следующие задачи, которые создают и публикуют конфигурацию выпуска веб-проекта Space Game. (Не добавляйте этот код в файл azure-pipelines.yml.)

- task: DotNetCoreCLI@2
  displayName: 'Build the project - Release'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

Для создания конфигурации отладки можно повторить эти две задачи, но заменить Release на Debug.

Так вы получите нужный результат, но что, если сборка усложнится или требования изменятся? Необходимо будет вручную найти и изменить оба варианта каждой задачи сборки. После добавления дополнительных требований к сборке необходимо также создать две задачи — одну для конфигурации отладки и одну для выпуска — для удовлетворения этих требований.

Лучше использовать шаблон.

Что такое шаблоны?

Шаблон позволяет определить распространенные задачи сборки один раз, а затем использовать их многократно.

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

Мара может определить задачи для сборки и опубликовать приложение как шаблон, а затем применить этот шаблон к каждой нужной конфигурации.

Определение шаблона

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

Теперь вы создадите шаблон, который может создать любую конфигурацию, определенную в файле проекта.

1. Во встроенной консоли Visual Studio Code создайте каталог templates в корневом каталоге проекта.

   mkdir templates
   

   На практике можно поместить файл шаблона в любое удобное расположение. Это не обязательно должен быть каталог templates.

2. В Visual Studio Code, выберите Файл > Создать файл. Затем, чтобы сохранить пустой файл под именем build.yml в каталоге templates проекта, выберите Файл > Сохранить. Примером может быть ~/mslearn-tailspin-spacegame-web/templates.

   Важно!

   Как и ранее, в Windows в списке Тип сохраняемого файла выберите YAML.

3. В Visual Studio Code добавьте в build.yml следующий код:

   parameters:
     buildConfiguration: 'Release'
   
   steps:
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
       zipAfterPublish: true
   

   Эти задачи похожи на те, что вы определили ранее для создания и публикации приложения. Но в шаблоне вы работаете с входными параметрами не так, как с обычными переменными. Существует два отличия:

   • В файле шаблона вы используете раздел parameters вместо variables для определения входных данных.
   • В файле шаблона вы используете синтаксис ${{ }} вместо $(), чтобы прочитать значение параметра. При чтении значения параметра вы включаете раздел parameters в его имя. Например, ${{ parameters.buildConfiguration }}.

Вызов шаблона из конвейера

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

1. В Visual Studio Code измените файл azure-pipelines.yml следующим образом.

   trigger:
   - '*'
   
   pool:
     vmImage: 'ubuntu-22.04'
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Debug'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Release'
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

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

   Можно увидеть, что шаблон вызывается один раз для каждой конфигурации. Каждая задача template использует аргумент parameters, чтобы передать имя конфигурации в шаблон.

Запуск конвейера

Теперь необходимо отправить изменения в GitHub и посмотреть, как выполняется конвейер.

1. Во встроенном терминале добавьте azure-pipelines.yml и templates/build.yml в индекс, зафиксируйте изменения и отправьте ветвь в GitHub.

   git add azure-pipelines.yml templates/build.yml
   git commit -m "Support build configurations"
   git push origin build-pipeline
   

2. В Azure Pipelines проследите за всеми шагами сборки.

   Пока конвейер выполняется, вы увидите, что процесс разворачивает задачи в шаблоне. Задачи, которые собирают и публикуют проект, выполняются дважды, по одному разу для каждой конфигурации сборки.

   

3. После завершения сборки вернитесь на страницу сводки и выберите опубликованный артефакт. Разверните папку drop.

   Конвейер создаст ZIP-файл для конфигурации сборки и конфигурации выпуска.

   

Объединение ветви с главной ветвью

Теперь у вас есть рабочий конвейер сборки, который выполняет все, что сейчас нужно Маре.

На практике вы можете отправить запрос на вытягивание, который объединит вашу ветвь build-pipeline с ветвью main.

Пока пропустим этот шаг. В следующем модуле вы узнаете о некоторых способах совместной работы на сайте GitHub, в том числе о способах отправки, проверки и слияния запросов на вытягивание.

Продолжить