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

Статья
08/17/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.

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

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

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

Перейдите в редактор конвейера, выбрав Изменить действие конвейера в сборке или выбрав Изменить на странице main конвейера.
В настоящее время конвейер выполняется в агенте 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` файле