Настройка конвейера

Статья
04/24/2023

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г.

Это пошаговое руководство по стандартным способам настройки конвейера.

Предварительное требование

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

Общие сведения о `azure-pipelines.yml` файле

Конвейер определяется с помощью YAML-файла в репозитории. Как правило, этот файл имеет имя azure-pipelines.yml и находится в корне репозитория.

Перейдите на страницу Конвейеры в Azure Pipelines, выберите созданный конвейер и щелкните Изменить в контекстном меню конвейера, чтобы открыть редактор YAML для конвейера.

Примечание

Инструкции по просмотру конвейеров и управлению ими на портале Azure DevOps см. в статье Навигация по конвейерам.

Изучите содержимое файла YAML.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

Примечание

Содержимое файла YAML может отличаться в зависимости от примера репозитория, с которым вы начали работу, или обновлений, выполненных в Azure Pipelines.

Этот конвейер выполняется всякий раз, когда команда отправляет изменения в главную ветвь репозитория или создает запрос на вытягивание. Он выполняется на компьютере Linux, размещенном в Корпорации Майкрософт. Процесс конвейера состоит из одного шага, который заключается в выполнении задачи Maven.

Изменение платформы для сборки

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

Перейдите в редактор конвейера, выбрав Изменить действие конвейера в сборке или выбрав Изменить на главной странице конвейера.
В настоящее время конвейер выполняется в агенте Linux:
```
pool:
  vmImage: "ubuntu-latest"
```
Чтобы выбрать другую платформу, например Windows или Mac, измените vmImage значение:
```
pool:
  vmImage: "windows-latest"
```
```
pool:
  vmImage: "macos-latest"
```
Выберите Сохранить , а затем подтвердите изменения, чтобы увидеть, как конвейер выполняется на другой платформе.

Добавление шагов

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

Откройте редактор YAML для конвейера.

Добавьте следующий фрагмент кода в конец файла YAML.

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: "JaCoCo"
    summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml"
    reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco"
    failIfCoverageEmpty: true

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

Сборка на нескольких платформах

Вы можете создать и протестировать проект на нескольких платформах. Один из способов сделать это — с помощью strategy и matrix. Переменные можно использовать для удобного переноса данных в различные части конвейера. В этом примере мы будем использовать переменную для передачи имени образа, который мы хотим использовать.

В файле azure-pipelines.yml замените следующее содержимое:

pool:
  vmImage: "ubuntu-latest"

со следующим содержимым:

strategy:
  matrix:
    linux:
      imageName: "ubuntu-latest"
    mac:
      imageName: "macOS-latest"
    windows:
      imageName: "windows-latest"
  maxParallel: 3

pool:
  vmImage: $(imageName)

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

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

Сборка с использованием нескольких версий

Чтобы создать проект с использованием разных версий этого языка, можно использовать matrix версии и переменную . На этом шаге можно либо создать проект Java с двумя разными версиями Java на одной платформе, либо запустить разные версии Java на разных платформах.

Примечание

В контексте нельзя использовать strategy несколько раз.

Если вы хотите выполнить сборку на одной платформе и нескольких версиях, добавьте приведенную ниже матрицу в azure-pipelines.yml файл перед задачей Maven и после vmImage.
```
strategy:
  matrix:
    jdk10:
      jdkVersion: "1.10"
    jdk11:
      jdkVersion: "1.11"
  maxParallel: 2
```
Затем замените эту строку в задаче Maven:
```
jdkVersionOption: "1.11"
```
на следующую:
```
jdkVersionOption: $(jdkVersion)
```
Обязательно измените $(imageName) переменную обратно на платформу по своему выбору.

Если вы хотите выполнить сборку на нескольких платформах и версиях, замените все содержимое файла azure-pipelines.yml перед задачей публикации следующим фрагментом кода:

trigger:
- main

strategy:
  matrix:
    jdk10_linux:
      imageName: "ubuntu-latest"
      jdkVersion: "1.10"
    jdk11_windows:
      imageName: "windows-latest"
      jdkVersion: "1.11"
  maxParallel: 2

pool:
  vmImage: $(imageName)

steps:
- task: Maven@4
  inputs:
    mavenPomFile: "pom.xml"
    mavenOptions: "-Xmx3072m"
    javaHomeOption: "JDKVersion"
    jdkVersionOption: $(jdkVersion)
    jdkArchitectureOption: "x64"
    publishJUnitResults: true
    testResultsFiles: "**/TEST-*.xml"
    goals: "package"

Выберите Сохранить , а затем подтвердите изменения, чтобы увидеть, как сборка выполняет два задания на двух разных платформах и пакетах SDK.

Настройка триггеров CI

Триггеры конвейера вызывают запуск конвейера. Можно использовать для trigger: запуска конвейера при отправке обновления в ветвь. Конвейеры YAML по умолчанию настраиваются с помощью триггера CI в ветви по умолчанию (обычно mainэто ). Триггеры можно настроить для определенных ветвей или для проверки запросов на вытягивание. Для триггера проверки запроса на вытягивание просто замените trigger: шаг на pr: , как показано в двух примерах ниже. По умолчанию конвейер выполняется для каждого изменения запроса на вытягивание.

Если вы хотите настроить триггеры, добавьте один из следующих фрагментов в начало azure-pipelines.yml файла.
```
trigger:
  - main
  - releases/*
```
```
pr:
  - main
  - releases/*
```
Можно указать полное имя ветви (например, main) или подстановочный знак, соответствующий префиксу (например, releases/*).

Параметры конвейера

Просмотреть и настроить параметры конвейера можно в меню Дополнительные действия на странице сведений о конвейере .

Снимок экрана: меню параметров конвейера и дополнительных действий.

Управление безопасностью - Управление безопасностью
Переименование или перемещение — измените имя конвейера и расположение папки.
Индикатор - состояния Добавление индикатора состояния в репозиторий
Удалить — удаляет конвейер, включая все сборки и связанные артефакты.
Запланированные запуски - Представление запланированных запусков

Выберите Параметры, чтобы настроить следующие параметры конвейера.

Снимок экрана: страница параметров конвейера.

В области Параметры конвейера можно настроить следующие параметры.

Обработка новых запросов на выполнение . Иногда требуется запретить запуск новых запусков в конвейере.
- По умолчанию обработка новых запросов на выполнение включена. Этот параметр позволяет выполнять стандартную обработку всех типов триггеров, включая запуски вручную.
- Приостановленные конвейеры позволяют обрабатывать запросы на выполнение, но эти запросы помещаются в очередь без фактического запуска. Если включена обработка новых запросов, выполнение возобновляется, начиная с первого запроса в очереди.
- Отключенные конвейеры не позволяют пользователям запускать новые запуски. Все триггеры также отключены при применении этого параметра.
Путь к файлу YAML . Если вам когда-либо потребуется направить конвейер на использование другого файла YAML, можно указать путь к нему. Этот параметр также может быть полезен, если необходимо переместить или переименовать файл YAML.
Автоматически связывать рабочие элементы, включенные в этот запуск . Изменения, связанные с определенным запуском конвейера, могут иметь связанные с ними рабочие элементы. Выберите этот параметр, чтобы связать эти рабочие элементы с выполнением. Если выбран параметр Автоматически связывать рабочие элементы, включенные в этот запуск , необходимо указать определенную ветвь или * для всех ветвей, которая используется по умолчанию. Если указать ветвь, рабочие элементы будут связаны только с запусками этой ветви. Если указать *, рабочие элементы будут связаны для всех запусков.
- Сведения о том, как получать уведомления о сбое запусков, см. в статье Управление уведомлениями для команды.

Управление безопасностью

Вы можете настроить безопасность конвейеров на уровне проекта на странице Дополнительные действия на целевой странице конвейеров и на уровне конвейера на странице сведений о конвейере.

Для обеспечения безопасности операций конвейера можно добавить пользователей во встроенную группу безопасности, задать отдельные разрешения для пользователя или группы или добавить пользователей к предопределенным ролям. Вы можете управлять безопасностью Azure Pipelines на веб-портале из контекста пользователя или администратора. Дополнительные сведения о настройке безопасности конвейеров см. в разделе Разрешения конвейера и роли безопасности.

Создание рабочего элемента при сбое

Конвейеры YAML не имеют параметра Создать рабочий элемент при сбое , например классические конвейеры сборки. Классические конвейеры сборки являются одним этапом, а создание рабочего элемента при сбое применяется ко всему конвейеру. Конвейеры YAML могут быть многоэтапными, а параметр уровня конвейера может быть неуместным. Чтобы реализовать создание рабочего элемента при сбое в конвейере YAML, можно использовать такие методы, как вызов REST API "Рабочие элементы — создание " или команду azure DevOps CLI az boards work-item create в нужной точке конвейера.

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

# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
  displayName: Succeed or fail
  type: boolean
  default: false

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:
- job: Work
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

  # This malformed command causes the job to fail
  # Only run this command if the succeed variable is set to false
  - script: git clone malformed input
    condition: eq(${{ parameters.succeed }}, false)

# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
  dependsOn: Work
  condition: failed()
  steps: 
  - bash: |
      az boards work-item create \
        --title "Build $(build.buildNumber) failed" \
        --type bug \
        --org $(System.TeamFoundationCollectionUri) \
        --project $(System.TeamProject)
    env: 
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: 'Create work item on failure'

Примечание

Azure Boards позволяет настроить отслеживание рабочих элементов с помощью нескольких различных процессов, таких как Agile или Basic. Каждый процесс имеет разные типы рабочих элементов, и не каждый тип рабочего элемента доступен в каждом процессе. Список типов рабочих элементов, поддерживаемых каждым процессом, см. в разделе Типы рабочих элементов (WIT).

В предыдущем примере параметры среды выполнения используются для настройки успешного или неудачного выполнения конвейера. При запуске конвейера вручную можно задать значение succeed параметра . Второй script шаг в первом задании конвейера оценивает succeed параметр и выполняется только в том случае, если succeed задано значение false.

Второе задание в конвейере зависит от первого задания и выполняется только в случае сбоя первого задания. Второе задание использует команду Azure DevOps CLI az boards work-item create для создания ошибки. Дополнительные сведения о выполнении команд Azure DevOps CLI из конвейера см. в статье Выполнение команд в конвейере YAML.

В этом примере используются два задания, но этот же подход можно использовать на нескольких этапах.

Примечание

Вы также можете использовать расширение Marketplace, например создание ошибки при сбое выпуска , которое поддерживает многоэтапные конвейеры YAML.

Дальнейшие действия

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

Или, чтобы расширить конвейер CI до конвейера CI/CD, включите задание развертывания с шагами по развертыванию приложения в среде.

Дополнительные сведения о разделах этого руководства см. в разделах Задания, Задачи, Каталог задач, Переменные, Триггеры или Устранение неполадок.

См. сведения о других доступных операциях с конвейерами YAML.

Настройка конвейера

Предварительное требование

Общие сведения о `azure-pipelines.yml` файле

Изменение платформы для сборки

Добавление шагов

Сборка на нескольких платформах

Сборка с использованием нескольких версий

Настройка триггеров CI

Параметры конвейера

Управление безопасностью

Создание рабочего элемента при сбое

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы

Настройка конвейера

Предварительное требование

Общие сведения о azure-pipelines.yml файле

Изменение платформы для сборки

Добавление шагов

Сборка на нескольких платформах

Сборка с использованием нескольких версий

Настройка триггеров CI

Параметры конвейера

Управление безопасностью

Создание рабочего элемента при сбое

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы

Общие сведения о `azure-pipelines.yml` файле