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

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, размещенной на серверах Microsoft. Процесс конвейера имеет один шаг, который предназначен для выполнения задачи 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)
  

• Нажмите "Сохранить, а затем подтвердите изменения, чтобы увидеть, как ваша сборка выполняет до трех задач на трех разных платформах.

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

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

Чтобы создать проект с помощью разных версий этого языка, можно использовать таблицу версий и переменную. На этом шаге можно создать проект 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). Триггеры можно настроить для определенных ветвей или для проверки pull request. Для триггера проверки запроса на вытягивание просто замените шаг trigger: на шаг pr:, как показано в двух примерах ниже. По умолчанию поток обработки запускается для каждого изменения в pull request.

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

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Можно указать полное имя ветви (например, main) или подстановочный знак, соответствующий префиксу (например, releases/*).

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

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

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

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

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

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

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

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

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

  

  • Чтобы получать уведомления при сбое выполнения задач, см. как управлять уведомлениями для команды.

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

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

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

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

Конвейеры YAML не имеют настройки Создать рабочий элемент при сбое, в отличие от классических конвейеров сборки. Классические конвейеры сборки являются одноступенчатыми, и создание рабочего элемента при сбое применяется ко всему конвейеру. Конвейеры YAML могут быть многоэтапными, и параметр уровня конвейера может быть несоответствующим. Чтобы реализовать создание рабочего элемента при сбое в конвейере YAML, можно использовать такие методы, как вызов REST API Work Items - Create или команда 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.

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

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

• .NET Core
• Контейнеры
• Go
• Java
• Node.js
• Python

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

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

Чтобы узнать, что ещё можно сделать в конвейерах YAML, см. справочник по схеме YAML.