Определение проекта, который следует развернуть в приложении Azure Functions из системы управления версиями - PullRequest
Новая
       16

Определение проекта, который следует развернуть в приложении Azure Functions из системы управления версиями

0 голосов
/ 23 июня 2019

У нас есть коллекция приложений-функций Azure в ядре c # net.Каждое приложение содержит небольшое количество функций Azure.Все функциональные приложения находятся в одном репозитории git.

Нам бы хотелось, чтобы некоторые из наших сред развертывались автоматически из источника (например, bitBucket или gitHub).

Как настроить проект так, чтобы Azureзнает, какой проект в источнике относится к какому созданному приложению-функции?

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

1 Ответ

1 голос
/ 23 июня 2019

Я бы рекомендовал использовать Azure DevOps (ранее VSTS) для развертывания в Azure, вы используете YAML для определения конвейера сборки, который может публиковать артефакт из каждого из ваших функциональных приложений.Затем артефакты обнаруживаются конвейером выпуска и могут быть развернуты в Azure.

Основными строительными блоками этого являются, во-первых, некоторые YAML, подобные этому в вашем конвейере сборки для каждого проекта: 

...

steps:
# a script task that let's you use any CLI available on the DevOps build agent, also uses a variable for the build config
- script: dotnet build MyFirstProjectWithinSolution\MyFirstProject.csproj --configuration $(buildConfiguration)
  displayName: 'dotnet build MyFirstProject'

# other steps removed, e.g. run and publish tests

- script: dotnet publish MyFirstProjectWithinSolution\MyFirstProject.csproj --configuration $(buildConfiguration) --output MyFirstArtifact
  displayName: 'dotnet publish MyFirstProject'

# a DevOps named task called CopyFiles (which is version 2 = @2), DevOps supplies lots of standard tasks you can make use of
- task: CopyFiles@2
  inputs:
    contents: 'MyFirstProjectWithinSolution\MyFirstArtifact\**'
    targetFolder: '$(Build.ArtifactStagingDirectory)'

# now publish the artifact which makes it available to the release pipeline, doing so into a sub folder allows multiple artifacts to be dealt with
- task: PublishBuildArtifacts@1
  displayName: 'publish MyFirstArtifact artifact'
  inputs:
    pathtoPublish: '$(Build.ArtifactStagingDirectory)\MyFirstProjectWithinSolution\MyFirstArtifact'
    artifactName: MyFirstArtifact

# now repeat the above for every project you need to deploy, each in their own artifact sub-folder

Затем вы создаете выпуск, который в своей простейшей форме выбирает артефакты и выполняет одно или несколько развертываний, вот простой, который развертывает два проекта функциональных приложений:

Simple Release Pipeline

На этапе развертывания (справа вверху) вы можете определить процесс выпуска, опять же в его простейшей форме вы можете просто развернуть прямо в производство или в слот, хотя до слотов функций не выходят из предварительного просмотраВы также можете запустить другое приложение-функцию, развернуть и протестировать там.

На этом снимке экрана показано простое развертывание, в котором используется стандартное развертывание приложения-функции Azure из DevOps Azure:

Deployment Tasks

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

Все или часть вышеперечисленного можно автоматизировать, нажав ветку (или другие триггеры, например, по расписанию).Уведомления и «шлюзы» также могут быть добавлены, если вы хотите вмешательство вручную перед выпуском или между этапами выпуска.

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

...