Поделиться через


Создание конвейера YAML с этапами

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Из этой статьи вы узнаете, как создать и запустить более сложный конвейер YAML с несколькими этапами и условиями. Пример конвейера включает этапы сборки, тестирования и развертывания, а также необязательные этапы для альтернативных развертываний и откатов. Этап отката позволяет быстро вернуться к стабильной версии, если что-то пойдет не так, повышая надежность и стабильность.

Этот код работает для большинства сценариев, но не включает требования к языку или платформе. На следующем шаге настройте конвейер для конкретных потребностей реализации.

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

Необходимые условия

Продукт Требования
Azure DevOps - Проект Azure DevOps.
— способность запуска потоков на хостинговых агентах Microsoft. Вы можете приобрести параллельное задание или запросить бесплатный уровень.
— Базовые знания о YAML и Azure Pipelines. Дополнительные сведения см. в разделе Создайте ваш первый конвейер.
Разрешения: -
     Чтобы создать пайплайн, пользователи должны находиться в группе "Участники", а для группы должно быть установлено разрешение Создать пайплайн сборки с значением 'Разрешено'. Члены групп администраторов сборки и администраторов проектов также могут управлять пайплайнами.
GitHub — учетная запись GitHub.
- Подключение службы GitHub для авторизации Azure Pipelines.
Лазурный Подписка Azure.

1. Создание начального конвейера

  1. В проекте Azure DevOps выберите Pipelines>Create Pipeline, а затем выберите GitHub в качестве расположения исходного кода.
  2. На экране "Выбор репозитория" выберите свой репозиторий.
  3. На экране Настройка конвейера выберите начальный конвейер.
  4. Сохраните конвейер.

2. Добавление этапа сборки

Стартовый конвейер, добавленный на предыдущем этапе, служил заполнителем. Удалите код начального конвейера и добавьте новый конвейер YAML с этапом сборки.

  1. Удалите весь код в конвейере.

  2. Замените код следующим YAML, который включает этап Build.

    trigger:
    - main
    
    pool:
      vmImage: 'ubuntu-latest'
    
    stages:
    - stage: Build
      displayName: 'Build Stage'
      jobs:
      - job: BuildJob
        displayName: 'Build Job'
        steps:
        - script: |
            echo "Restoring project dependencies..."
          displayName: 'Restore dependencies'
        - script: |
            echo "Running unit tests..."
          displayName: 'Run unit tests'
    

На этом этапе Build и в ходе всего тестового конвейера предусмотрены задачи скрипта заполнителя. При создании рабочего потока данных замените команды-заполнители, такие как Restoring project dependencies..., на фактический код.

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

3. Добавление этапа тестирования

Этап Test выполняет тесты в проекте и публикует результаты теста в Azure DevOps. Дополнительные сведения о публикации результатов теста см. в задаче Публикация результатов теста.

Этап Test выполняется только в том случае, если этап Build завершается успешно, и этап не может быть пропущен.

Добавьте этап Test после этапа Build в конвейере.

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

Этап тестирования включает атрибут, который устанавливает isSkippable в false. Если isSkippable задано значение false, невозможно пропустить этап. Параметр пропускать этап также отключен в пользовательском интерфейсе Azure DevOps.

снимок экрана этапа, который не может быть пропущен.

4. Развертывание на промежуточный сервер

Добавьте этап DeployToStaging после этапа Test в конвейере.

Этап DeployToStaging зависит от этапа Test для выполнения. На этапе DeployToStaging есть два разных задания — DeployStagingJob и DeployStagingJobWithValidation. DeployStagingJob должен содержать код для развертывания стейджинг-задачи на стейджинг-ресурсы, такие как сервер стейджинга.

Задание DeployStagingJobWithValidation содержит все проверки, связанные с вашим промежуточным развертыванием. Для задания DeployStagingJobWithValidation требуется утверждение вручную. Задача ручной проверки приостанавливает выполнение конвейера и ожидает ручного взаимодействия. Пользователь должен подтвердить этап перед продолжением выполнения. Наличие утверждения вручную в конвейере добавляет еще один уровень безопасности, помогает снизить риски и гарантирует, что все изменения проверяются соответствующими заинтересованными лицами.

Пул для ручного утверждения server. Проверки вручную выполняются только в пуле серверов.

- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

5. Развертывание в рабочей среде

Добавьте этап DeployToProduction после этапа DeployToStaging в конвейере.

На этапе DeployToProduction приложение развертывается в рабочей среде, но только если этап DeployToStaging успешно выполнен, а исходная ветвь — main или release.

На этапе DeployToProduction есть два разных задания — DeployProductionJob и waitForValidation.

Задача ручной проверки в waitForValidation добавляет второй этап проверки человека для обеспечения безопасности и контроля качества. Мы также использовали задачу проверки вручную на этапе DeployToStaging.

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

6. Добавить дополнительные альтернативные этапы производства и этапы отката

При необходимости можно добавить два этапа DeployToAlternateProduction и Rollback после этапа DeployToProduction.

DeployToAlternateProduction и Rollback вручную помещаются в очередь. Этап DeployToAlternateProduction позволяет подготовить рабочую среду резервного копирования в случае сбоя основной среды. Среда может быть Azure DevOps Environment или другой, например, у другого облачного провайдера. Это повышает общую надежность и доступность приложения. Кроме того, может потребоваться использовать альтернативную среду развертывания для аварийного восстановления или тестирования и проверки. Для более сложных стратегий развертывания смотрите в разделах Задания развертывания и Добавление этапов, зависимостей и условий.

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

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

Просмотр всего конвейера YAML

Вот весь процесс со всеми упомянутыми этапами.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build Stage'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: |
        echo "Restoring project dependencies..."
      displayName: 'Restore dependencies'
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'


- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

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