Как развернуть несколько приложений (монорепозиторий) с Azure и NX - PullRequest
0 голосов
/ 29 мая 2020

Я использую инструменты NX для управления монорепозиторием с несколькими приложениями, и я изо всех сил пытаюсь понять, как развертывать с помощью Azure и выпускать конвейеры.

Отказ от ответственности : Я новичок в Azure и DevOps в целом.

Я понимаю следующее: я создаю конвейер (не конвейер выпуска, а просто «обычный», если это имеет смысл ) и подключите к нему yml. Кроме того, конвейер связан с репо на Azure Repos, что означает, что каждый раз, когда я подключаюсь к этому репо sh, он запускает конвейер и запускает команды yaml. С помощью этих команд я запускаю lint, test и builds.

Это то, что я могу сделать и могу понять, следующее становится более неясным :

Сборка выполняется должен создать артефакт, если я использую / объединяю мастер, который я могу обусловить. Теперь я могу создать конвейер выпуска, который будет запускаться, когда репо, с которым он связан, создаст артефакт. Этот конвейер выпуска может затем отправить этот артефакт в службу приложения, которая является слотом, в котором будет жить приложение.

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

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

Итак, это в основном мое понимание всего этого. Теперь вот вопросы:

  1. Что такое тег сборки и где он находится? Это как-то связано с артефактом?
  2. Идея состоит в том, чтобы создать один тег сборки для каждого артефакта, верно?
  3. Мне не удалось создать тег сборки, как мне это сделать?
  4. Как правильно заархивировать и опубликовать sh артефакты?

    Вот yaml, который я использую:

jobs:
  - job: Lint
    steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '12.x'
        displayName: 'Install Node.js'
      - task: Npm@1
        displayName: 'Npm install'
      - pwsh: 'npm run nx affected -- --target=lint --parallel --base=origin/master --maxParallel=4'
        displayName: 'Running lint'

  - job: Test
    steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '12.x'
        displayName: 'Install Node.js'
      - task: Npm@1
        displayName: 'npm install'
      - pwsh: 'npm run nx affected -- --target=test --parallel --code-coverage --base=origin/master --maxParallel=4'
        displayName: 'Running tests'

  - job: Build
    steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '12.x'
        displayName: 'Install Node.js'
      - task: Npm@1
        displayName: 'npm install'
      - pwsh: 'npm run nx affected -- --target=build --parallel --base=origin/master --prod'
        displayName: 'Running build'
      - pwsh: |
          npm run nx affected:apps -- --base=HEAD~1  --head=HEAD | grep -E '( - )(\w|-|\d|_)+' | sed -E 's/ - /##vso[build.addbuildtag]/g'
        displayName: 'Adding build tags'

При запуске работают тест, lint и сборки, но я не думаю, что он добавляет тег сборки, вот журнал:

enter image description here

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

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

5) Итак, последний вопрос: как я могу создать несколько артефактов и хорошо ли это делать?

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

1 Ответ

1 голос
/ 01 июня 2020

1, вы можете добавить теги для сборки со страницы пользовательского интерфейса (страница сводки сборки, см. Ниже) или используя Rest api . Его можно использовать для фильтрации между сборками. Если ваш конвейер сборки сгенерировал несколько артефактов, теги сборки не смогут фильтровать артефакты, созданные в одной сборке.

enter image description here

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

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

См. ниже пример yaml: я использовал задачу двух архивных файлов, чтобы отдельно упаковать артефакты сборки для app1 и app2. И сохраните заархивированные артефакты в папке $(Build.ArtifactStagingDirectory). Затем задача публикации sh артефактов опубликует sh артефакты в azure облаке DevOps. (Конвейер выпуска загрузит артефакты для развертывания на ваш сервер приложений)

- task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: $(system.defaultworkingdirectory)/app1/dist
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/app1/dist1.zip'
        includeRootFolder: false
      enabled: true
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: $(system.defaultworkingdirectory)/app2/dist
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/app2/dist2.zip'
        includeRootFolder: false
      enabled: true


    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: $(Build.ArtifactStagingDirectory)/
        artifactName: build

3. Затем вы можете использовать несколько этапов в конвейере выпуска и использовать Azure задачу развертывания службы приложений . Для примера ниже:

На первом этапе добавьте Azure App Service Deploy task и установите для пакета значение $(System.DefaultWorkingDirectory)/**/app1/dist1.zip для развертывания app1. И на втором этапе установите для него значение $ (System.DefaultWorkingDirectory) / ** / app2 / dist2.zip для развертывания app2. enter image description here

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

trigger:
  paths:
    include:
    - root/app1/*

Надеюсь, что это поможет!

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