时间戳

首页 > 解决方案 > 当我推送整个解决方案的存储库时，是否可以只部署更新的 Azure 功能项目？

azure-devops - 当我推送整个解决方案的存储库时，是否可以只部署更新的 Azure 功能项目？

问题描述

我需要重构一个 .Net Web API，我正在考虑迁移到无服务器，并且我正在尝试了解将代码迁移到 Azure Functions 的最佳选择。

据我了解，降低成本和冷启动时间的正确方法是拆分 API：拥有多个小型 Web api 比使用所有方法的单个 web api 好得多。小 api 消耗更少的内存和更快的冷启动。

在同一个项目中拥有更多功能并不能解决问题，因为它们都将部署在同一个功能应用程序中，因此一个 dll、高内存、冷启动缓慢。所以我应该创建几个 Azure Function Projects 并将它们中的每一个部署在不同的 Function App 中。

如果以上所有内容都正确，我们终于解决了问题：我将构建代码和 repo，以便我有一个包含多个 Azure 函数项目的解决方案。如何拥有 CI/CD (Azure DevOps)，以便在我推送存储库时仅部署更新/修改/新的 Azure 函数项目？我只需要部署修改后的 Azure 函数项目，以免所有函数应用程序（以及代码未更改的应用程序）都变冷。

这不太重要，但我还需要为所有 API 提供一个 URL，因此https://myapi.azurewebsites.net/api/Function1、https://myapi.azurewebsites.net/api/Function2等而不是https://myapi1.azurewebsites.net/api/Function1，https://myapi2.azurewebsites.net/api/Function1等。使用上述结构可以吗？

标签： azure-devopsazure-functionsazure-pipelines

解决方案

您需要有多个 CI/CD 管道，触发器仅限于特定文件夹：

trigger:
  paths:
    include:
    - function-a/*
    exclude:
    - '*'

function-a为此，只有在文件夹中完成更改时，您才会触发管道。为了限制开发管道所需的工作，您应该考虑使用模板。您可以在此处找到有关此的更多信息：

In this way you will avoid repeating yourself.

EDIT

To unify your API you can use Azure Functions Proxies

With this feature, you can specify endpoints on your function app that are implemented by another resource. You can use these proxies to break a large API into multiple function apps (as in a microservice architecture), while still presenting a single API surface for clients.

推荐阅读