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

  • Статья

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/*).

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

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

Screenshot of pipeline settings and more actions menu.

  • Управление безопасностью управления безопасностью -
  • Переименование и перемещение . Измените имя конвейера и расположение папки. Screenshot of rename or move pipeline page.
  • Эмблема состояния Добавление индикатора - состояния в репозиторий
  • Delete — удаляет конвейер, включая все сборки и связанные артефакты.
  • Представление запланированных запусков - запланированных запусков

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

Screenshot of pipeline settings page.

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

  • Обработка новых запросов на выполнение. Иногда требуется запретить запуск новых запусков в конвейере.

    • По умолчанию обработка новых запросов запуска включена. Этот параметр позволяет выполнять стандартную обработку всех типов триггеров, включая запуски вручную.
    • Приостановленные конвейеры позволяют обрабатывать запросы выполнения, но эти запросы помещаются в очередь без фактического запуска. При включении обработки нового запроса запустите возобновление обработки, начиная с первого запроса в очереди.
    • Отключенные конвейеры не позволяют пользователям запускать новые запуски. Все триггеры также отключены при применении этого параметра. Все политики сборки, использующие отключенный конвейер, будут отображать сообщение "Не удается выполнить сборку" рядом с политикой сборки в окне обзора pr и состояние политики сборки будет нарушено.

  • Путь к файлу YAML — если вам когда-либо нужно направить конвейер для использования другого ФАЙЛА YAML, можно указать путь к нему. Этот параметр также может быть полезным, если вам нужно переместить или переименовать файл YAML.

  • Автоматическое связывание рабочих элементов, включенных в этот запуск . Изменения, связанные с заданным запуском конвейера, могут иметь рабочие элементы, связанные с ними. Выберите этот параметр, чтобы связать эти рабочие элементы с выполнением. При выборе автоматического связывания рабочих элементов, включенных в этот запуск , необходимо указать определенную ветвь или * для всех ветвей, которая является значением по умолчанию. Если указать ветвь, рабочие элементы связаны только с запусками этой ветви. Если указать *, рабочие элементы связаны для всех запусков.

    Screenshot of setting to automatically link work items included in this run.

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

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

Screenshot of pipeline security menu options.

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

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

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

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

# 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 command для создания ошибки. Дополнительные сведения о выполнении команд Azure DevOps CLI из конвейера см. в разделе "Выполнение команд" в конвейере YAML.

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

Примечание.

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

Следующие шаги

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

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

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

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