Как структурировать конвейеры Azure Devops для сред тестирования и выпуска?

Я новичок в Azure DevOps и хочу создать правильные структуры конвейера / выпуска для своих проектов. Я изо всех сил пытаюсь понять, как я буду создавать свой код, передав правильное значение для моих конфигураций сборки.

Я создал свое репо и ветки:

main (основная ветка для выпущенного / подлежащего выпуску кода)

feature / add_new_customer (функциональные ветки для каждой работы)

uat (ветка, объединяющая несколько функций, фиксируется специально для тестирования перед выпуском)

Я создал конвейер сборки, и в результате был создан файл azure-pipelines.yaml, который я использовал для сборки и публикации файлов сборки. Это запускается из моих веток:

trigger:
- main
- feature/*
- uat

Все хорошо до сих пор. Но это было путем определения конфигурации сборки статически / жестко в yaml

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  **buildConfiguration: 'Release'**

Теперь я добавил в свой конвейер переменную BuildConfig и установил UAT, чтобы я мог ссылаться в своем yaml следующим образом:

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  **buildConfiguration: '$(BuildConfig)'**

и это позволяет мне динамически настраивать конфигурацию сборки, но если я создаю другой конвейер, скажем, для сборки моей сборки выпуска из основной ветки, это создает azure-pipelines-1.yaml, который должен быть неправильным, поскольку тогда мне придется дублировать их файлы просто для смены ветки триггера?

Есть ли правильный способ создавать сборки для разных сред на основе ветки, которую я проверяю? Я видел среды, но они, кажется, предлагают мне виртуальные машины или Kubernetes? Я просто хочу создать устаревшее приложение веб-формы .net framework, поэтому не нужно ничего особенного.

Я еще не приступил к развертыванию !!! : D


azure-devops azure-pipelines azure-pipelines-tasks
person PAblo    schedule 12.02.2021    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Это можно сделать двумя способами:

  • Параметр condition: в задаче сборки
  • YAML If Операторы, которые выборочно устанавливают переменные.

Любой из них будет работать в вашем сценарии, я считаю, что в вашем случае лучше всего использовать оператор if. Вот как это будет выглядеть на простом примере:

name: Stackoverflow-Example-Variables
trigger:
    - main
    - feature/*
    - uat
stages:
    - stage: your_build_stage
      variables:
        - name: solution
          value: '**/*.sln'
        - name: buildPlatform
          value: 'Any CPU'
        - name: buildConfiguration
          ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}:
            value: 'Release'
          ${{ if ne(variables['Build.SourceBranch'], 'refs/heads/main') }}:
            value: 'UAT'
      displayName: "Build Solution"
      jobs:
        - job: output_message_job
          displayName: "Output Message Job"
          pool:
            vmImage: "ubuntu-latest"
          steps:
            - powershell: |
                Write-Host ${{ variables.buildConfiguration }}
                Write-Host $(Build.SourceBranch)
person Max Morrow    schedule 12.02.2021
comment
Это прекрасно, спасибо. Именно то, что мне нужно. Одно быстрое продолжение, если можно, вы бы теперь создали 3 отдельных конвейера выпуска или один конвейер со стадиями для dev / qa / release? Если последнее, как мне определить, какие артефакты нужно получить для правильной сборки / среды? - person PAblo; 14.02.2021
comment
Итак, поскольку вы используете YAML, вы захотите включить этапы выпуска в тот же конвейер, что и ваша сборка. Я лично рекомендую придерживаться двух конвейеров, каждый из которых способен выполнять сборку и выпуск. Можно было бы собрать и развернуть Dev / QA, запущенную из ветки разработки или rc / *. Второй будет развернут в UAT / Production, запущен из main / master. В конфигурацию вашей среды также включите проверки утверждения для QA / UAT / Prod. - person Max Morrow; 14.02.2021