Упражнение. Создание нескольких конфигураций с помощью шаблонов
В предыдущих упражнениях вы реализовали конвейер, который создает веб-сайт Space Game . Вы начали со скрипта, который выполнял каждое действие сборки, и сопоставили каждое действие с соответствующей задачей конвейера. Выходные данные конвейера — это файл .zip , содержащий скомпилированное веб-приложение.
В этом упражнении вы используете шаблон для определения задач сборки, которые могут создать любую конфигурацию, определенную в файле проекта. Шаблоны позволяют определять логику один раз, а затем многократно использовать ее. Шаблоны объединяют содержимое нескольких файлов YAML в один конвейер.
Совет
Этот шаг в модуле необязателен. Если вы не хотите узнать о шаблонах в настоящее время, перейдите к следующему шагу, очистите среду Azure DevOps. Дополнительные сведения о шаблонах см. в разделе "Типы шаблонов и использование".
Давайте узнаем, как дела у Мары и Амиты.
Демоверсия
Маре не терпится поделиться результатами. Она находит Амиту, чтобы показать свой конвейер сборки.
Амита: Я впечатлен, что вы получили эту работу так быстро! На самом деле, я просто прихожу, чтобы увидеть вас, потому что я получил электронное письмо, сказав мне, что сборка была готова. Спасибо! Я вижу, что конвейер создает только конфигурацию выпуска. Мы также используем отладочные сборки, чтобы получить дополнительную информацию, если приложение завершает работу. Это можно добавить?
Мара: Абсолютно. Я забыла про отладочные сборки во время настройки. Давай добавим их вместе?
Амита: Вы показали мне ФАЙЛ 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
.
Это даст вам результат, который вы ищете, но что происходит, когда сборка становится более сложной или ваши требования изменяются? Вам потребуется вручную найти и изменить оба варианта каждой задачи сборки. После добавления дополнительных требований к сборке необходимо также создать две задачи, одну для конфигурации отладки и одну для выпуска, чтобы удовлетворить эти требования.
Лучше использовать шаблон.
Что такое шаблоны?
Шаблон позволяет определить распространенные задачи сборки один раз, а затем использовать их многократно.
Шаблон вызывается из родительского конвейера как шаг сборки. Вы можете передавать в шаблон параметры из родительского конвейера.
Мара может определить задачи для создания и публикации приложения в качестве шаблона, а затем применить этот шаблон к каждой конфигурации, которую она нуждается.
Определение шаблона
Помните, что шаблон позволяет определить распространенные задачи сборки один раз, а затем использовать их повторно. Вы вызываете шаблон из родительского шаблона в качестве шага сборки и передаете параметры в шаблон из родительского конвейера.
Теперь вы создадите шаблон, который может создать любую конфигурацию, определенную в файле проекта.
В интегрированной консоли Visual Studio Code в корне проекта создайте каталог шаблонов .
mkdir templates
На практике вы можете поместить файл шаблона в любое расположение. Их не нужно помещать в каталог шаблонов .
В Visual Studio Code, выберите Файл > Создать файл. Затем, чтобы сохранить пустой файл под именем build.yml в каталоге templates проекта, выберите Файл > Сохранить. Примером может быть ~/mslearn-tailspin-spacegame-web/templates.
Внимание
Как и раньше, в Windows в списке типов "Сохранить как тип " выберите YAML.
В 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 }}
.
- В файле шаблона вы используете раздел
Вызов шаблона из конвейера
Теперь вы вызовете шаблон, который вы только что создали из конвейера. Это можно сделать один раз для конфигурации отладки, а затем повторить процесс конфигурации выпуска.
В Visual Studio Code измените azure-pipelines.yml , как показано здесь:
trigger: - '*' pool: vmImage: ubuntu-latest 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()
trigger: - '*' pool: name: 'Default' #replace if needed with name of your agent pool 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 и увидите выполнение конвейера.
Во встроенном терминале добавьте 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
В Azure Pipelines проследите за всеми шагами сборки.
Пока конвейер выполняется, вы увидите, что процесс разворачивает задачи в шаблоне. Задачи, которые создают и публикуют проект, выполняются два раза один раз для каждой конфигурации сборки.
Когда сборка завершится, вернитесь на страницу сводки и выберите опубликованный артефакт, как и раньше. Разверните папку удаления.
Конвейер создаст ZIP-файл для конфигурации сборки и конфигурации выпуска.
Объединение ветви с главной ветвью
Теперь у вас есть рабочий конвейер сборки, который выполняет все, что сейчас нужно Маре.
На практике вы можете отправить запрос на вытягивание, который объединит вашу ветвь build-pipeline
с ветвью main
.
Пока пропустим этот шаг. В следующем модуле вы узнаете, как взаимодействовать с командой на GitHub, включая отправку, проверку и слияние запросов на вытягивание.