Конвейер Azure Devops с дополнительным этапом, запускаемым вручную

Я использую конвейеры YAML Azure DevOps и имею два этапа: один — развертывание в разработке (запускается при фиксации в мастере), а второй — проверка запросов на включение (выполнение тестов и статический анализ). Эти этапы выполняются на основе переменных, например. variables['Build.Reason'] или variables['Build.SourceBranchName'].

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

Я хочу, чтобы автор вручную запускал развертывание для разработки из запроса на включение (например, из-за изменений в инфраструктуре, переменных среды и т. д.), чтобы убедиться, что все работает, прежде чем изменения будут объединены в исходную версию.

Пример 1: я меняю только одну функцию. Я хочу, чтобы конвейер успешно выполнил статический анализ и тесты, а затем объединил PR.

Пример 2. Я интегрирую новую внешнюю службу (например, электронную почту) и хочу убедиться, что все работает. Таким образом, конвейер запустит статический анализ и тесты и успешно завершится (и позволит мне выполнить слияние, если я захочу). Однако, поскольку это более серьезное изменение при внешней интеграции, на этом этапе я хочу запустить развертывание для разработки и проверить, все ли работает. Это по-прежнему делается из PR, а не из мастера, потому что я хочу исправить проблемы, если они возникнут, до того, как изменение будет передано в исходную версию.

В обоих случаях (Пример1 и Пример2) после того, как mege to master изменения будут развернуты в dev.

Что я пробовал до сих пор

  • Использование задачи ManualValidation@0: неприменимо, потому что тогда конвейер не будет успешным. Поскольку конвейер должен пройти до запроса на слияние, автор не может объединить его без развертывания в dev.
    Я не пробовал задания по развертыванию, но подозреваю, что они работают аналогично.
  • Используйте параметр, например DeployDevFromPR, который должен указывать, должен ли конвейер проверять код или развертывать его. Затем установите две политики ветвей: одну автоматическую и обязательную (проверки), а другую вручную и необязательную (развертывание). Однако нет возможности установить переменную env из представления PR (если только автор не запросит конвейер снова), поэтому проверка выполняется вручную.
  • Принимайте решение на основе переменной variables['Build.QueuedBy']: значение будет другим, когда конвейер запускается автоматически. Для пользователя указано его имя пользователя, а для автоматических триггеров — «Microsoft.VisualStudio.Services.TFS». Однако это не работает, если пользователь хочет перезапустить конвейер проверки (тогда пользователем будет QueuedBy).

Могу ли я каким-то образом добиться желаемого эффекта, чтобы разрешить пользователю развертывание из PR вручную, не блокируя слияние?

Спасибо


1
63
2

Ответы:

Решено

Я использую конвейеры Azure DevOps YAML и имею два этапа: один — развертывание в разработке (запускается при фиксации в мастере), а второй — проверка запросов на извлечение (выполнение тестов и статический анализ).

Вместо использования одного конвейера с двумя этапами рассмотрите возможность разделения конвейера на две части:

  • Тестовый конвейер: запускает тесты и статический анализ.
  • Развертывание конвейера: развертывает код.

После разделения конвейеров создайте политику сборки в разделе Build Validation для каждого из них:

  • Политика тестового конвейера должна быть настроена по мере необходимости, т. е. сборка всегда должна выполняться как часть проверки запроса на включение.
  • Политика конвейера развертывания должна быть установлена ​​как необязательная: создатель PR должен решить, следует ли запускать эту сборку как часть проверки запроса на включение или нет.

Пример политики для конвейера развертывания:


В зависимости от вашего требования к решению с одним конвейером вы можете рассмотреть возможность оценки переменной из группы переменных, чтобы предотвратить запуск stage3 для развертывания Dev во время проверки PR, поскольку такие значения переменных находятся за пределами определения конвейера и обрабатываются во время выполнения конвейера.

trigger:
- master

pool:
  vmImage: ubuntu-latest

stages:
- stage: stage1
  condition: and(
                eq(variables['Build.Reason'], 'IndividualCI'),
                eq(variables['Build.SourceBranchName'], 'master')
              ) 
  jobs:
  - job: DeployToDevUponCI
    steps:
    - pwsh: |
        Write-Host "This is stage 1 deploying to Dev upon CI trigger"

- stage: stage2
  dependsOn: []
  condition: eq(variables['Build.Reason'], 'PullRequest')
  jobs:
  - job: Tests
    steps:
    - pwsh: |
        Write-Host "This is stage 2 running tests upon PR validation trigger"
        Write-Host "##vso[build.addbuildtag]stage2succeeded" # Add Build tag to filter the latest artifacts for download during stage3
    - publish: $(System.DefaultWorkingDirectory)
      artifact: drop$(Build.BuildId)

- stage: stage3
  dependsOn: stage2
  variables:
  - group: VG-DeployDevUponPR
  condition: eq(variables['DeployDevUponPR'], 'True')
  jobs:
  - job: DeployToDevUponPR
    steps:
    - task: DownloadPipelineArtifact@2
      inputs:
        buildType: 'specific'
        project: 'TheProjectName'
        definition: 'DeployDevUponPR'
        buildVersionToDownload: 'latest'
        tags: 'stage2succeeded'
        targetPath: '$(Pipeline.Workspace)'
    - pwsh: |
        Write-Host "This is stage 3 deploying to Dev upon CI trigger"
        tree $(Pipeline.Workspace)
        Write-Host "DeployDevUponPR - $(DeployDevUponPR)"
        Write-Host "After deployment - Reset the variable DeployDevUponPR in variable group 36 as false"
        az pipelines variable-group variable update --group-id 36 `
          --name DeployDevUponPR `
          --org $(System.CollectionUri) `
          --project $(System.TeamProject) `
          --value False
      env: 
        AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
      displayName: Reset the variable DeployDevUponPR in variable group 36 as false
      condition: always()

   

Когда конвейер запускался PR, stage3 всегда пропускался, пока вы вручную не установили значение переменной в группе переменных как True. Статус сборки проверки PR также был успешным. А когда вы захотите развернуть stage3, вы можете создать новый запуск только с выбранным stage3, который не будет отображаться на странице PR. Вы также можете использовать сценарий CLI Azure DevOps для обновления всех необходимых переменных среды в группе переменных во время stage2 для использования stage3.

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


Интересные вопросы для изучения

Как запретить принудительную отправку только на главную, но при этом разрешить прямую (не принудительную) отправку в репозиториях git Azure DevOpsКак проверить, является ли данный аргумент синтаксически допустимым коммитом или синтаксически допустимым диапазоном изменений?Уменьшение объема хранилища пакетов Azure DevopsНайдите последний коммит, который изменил файл с заданным именем в GitКак я могу получить главу ветки с недопустимыми символами?Как запретить принудительную отправку только на главную, но при этом разрешить прямую (не принудительную) отправку в репозиториях git Azure DevOpsAzure Pipelines — обработка одинаковых имен переменных в разных группах переменныхНе могу найти нужные артефактыУменьшение объема хранилища пакетов Azure DevopsКак создать скрипт в учетной записи автоматизации для получения квот и используемой емкости для каждого общего файлового ресурса