Развертывание приложения Vue.js с использованием конвейера выпуска Azure DevOps

С точки зрения CI

Должен быть только один build pipeline, который будет создавать артефакт независимо от среды, в которой он будет работать.

.env.prod можно использовать для развертывания артефактов в любых средах (Development, Production и т. Д.)

Вы должны предоставить конфигурацию с токенами, которые будут заменены на этапе развертывания / выпуска:

env_key1=#{token_key1}#
env_key2=#{token_key2}#
env_key3=#{token_key3}#

Поэтому просто соберите проект и опубликуйте артефакт, используя единый файл конфигурации для всех сред.

С точки зрения CD

Я бы рекомендовал использовать одиночный release pipeline с несколькими этапами (Development, Production и т. Д.).

Предоставьте отдельный variables groups на основе stages. Это позволяет хранить переменные отдельно, логически сгруппировать и использовать Azure Key Vault как источник секретов. Имена переменных должны совпадать с токенами среды (без префикса и суффикса).

Добавьте любые Task в Stage, который найдет и заменит жетоны.

В настоящее время я использую расширение Replace Tokens из магазина. В зависимости от stage будет подставлена ​​другая группа переменных. Replace Tokens задача выполняет всю работу автоматически, например. сканирует js файлы и заменяет токены. Префикс и суффикс токена по умолчанию: #{ }#, но задача позволяет указать желаемый вариант.

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

- script: |
    npm install
    npm run test:unit
    if [ $? -ne 0 ]; then
        exit 1
    fi
    npm run build-prod
  condition: and(succeeded(), not(in(variables['Build.Reason'], 'PullRequest', 'Manual')))
  displayName: 'npm install, test and build for prod'

- script: |
    npm install
    npm run test:unit
    if [ $? -ne 0 ]; then
        exit 1
    fi
    npm run build
  condition: and(succeeded(), in(variables['Build.Reason'], 'PullRequest', 'Manual'))
  displayName: 'npm install, test and build for test'

Так что краткая разбивка по сценариям. Если сборка была частью PullRequet или руководства, нам нужна промежуточная сборка, в которой используется сценарий сборки по умолчанию. В противном случае мы предполагали, что сборка предназначена для производства (вам понадобятся некоторые политики веток, чтобы обеспечить это). Затем конвейер выпуска проверил тег сборки, который мы установили следующим образом:

- task: PowerShell@2
  condition: and(succeeded(), not(in(variables['Build.Reason'], 'PullRequest', 'Manual')))
  inputs:
    targetType: 'inline'
    script: 'Write-Host "##vso[build.addbuildtag]release"'

- task: PowerShell@2
  condition: and(succeeded(), in(variables['Build.Reason'], 'PullRequest', 'Manual'))
  inputs:
    targetType: 'inline'
    script: 'Write-Host "##vso[build.addbuildtag]test"'

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

Если вы используете что-то подобное, последний шаг - фильтровать сборки, когда они попадают в конвейер выпуска, на основе тега сборки и ветки.