Я пытаюсь развернуть приложение ReactJS в своем веб-приложении Azure с помощью DevOps Azure. Я создал для него проект DevOps и пытаюсь настроить конвейер непрерывной интеграции, чтобы каждый коммит для мастера запускал новую сборку и развертывал ее в веб-приложении. Файл azure-pipelines.yml, в котором указаны инструкции по сборке, выглядит следующим образом:
# Node.js with React
# Build a Node.js project that uses React.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript
pool:
vmImage: 'Ubuntu 16.04'
trigger:
- master
steps:
- task: NodeTool@0
inputs:
versionSpec: '8.x'
displayName: 'Install Node.js'
- script: |
npm install
npm run build
displayName: 'npm install and build'
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
includeRootFolder: false
- task: PublishBuildArtifacts@1
Я создал этот файл, используя инструкции, приведенные на Сборка, тестирование и развертывание приложений Javascript в конвейерах Azure
Сборка прошла успешно, и я создал выпуск для сборки, используя следующие настройки:
Настройка задачи конвейера выпуска Azure
(развертывание службы приложений Azure> Тип приложения: веб-приложение> Пакет / папка: $ (System.DefaultWorkingDirectory) / ** / *. Zip)
Я также настроил физический путь для веб-приложения на Azure, чтобы он был site \ wwwroot \ build
В первый раз, когда я создаю сборку и выпускаю ее, она отлично разворачивается, и я вижу изменения, отраженные в веб-приложении. Однако , каждая последующая сборка не обновляется автоматически для отображения в веб-приложении. Используя диагностическую консоль в Kudu, я вижу, что новые сборки идут на один каталог глубже, например, следующая сборка будет иметь физический путь к сайту \ wwwroot \ build \ build. Чтобы увидеть новую сборку, мне приходится каждый раз вручную менять путь к веб-приложению.
Изменить. Ниже приведены некоторые снимки параметров веб-приложения Azure и консоли в Kudu.
У меня такой вопрос : Как я могу настроить весь этот процесс так, чтобы новые сборки заменяли старые сборки в веб-приложении, и чтобы они не были вложены в старую сборку?