我的目标是让以前的版本是不可变的：它们的定义和功能不应该改变。API 是使用基于 .NET 4.7.2（依赖原因）的 ASP.NET Core 构建的，并作为 Azure 应用服务托管。

最好，我不想通过添加“版本知识”来弄乱我的代码。此外，如果版本可以托管在相同的基本 URL 下，那也很好。

我的研究：

1. ASP.NET API 版本控制

有了这个，您可以完全控制应用程序中的版本控制。但是当新版本发布时，所有旧版本也会更新，因此可以更改。这意味着您不能改变任何现有函数，但必须创建新版本，就像 Scott 在 URL PATH SEGMENT VERSIONING 中所做的那样。

2. Azure 部署槽

正如文档所解释的，这应该用于分期。但是，这也可以用于“存储”您的版本，因为每个部署槽都是托管的，彼此之间没有任何关系。

3. 虚拟应用程序

将版本托管为虚拟应用程序也是一种选择。但是，应用服务的所有设置都在这些虚拟应用程序之间共享。这意味着在更改任何设置时，这将影响每个版本。

4. 用于容器的 Azure Web 应用

我对此的了解有限，但从我所阅读的内容来看，这也是一种选择。根据应用程序的版本创建图像，将这些图像上传到Azure Container Registery。然后使用这些图像为每个版本创建一个应用服务。

1. az devops login --organization https://dev.azure.com/XXXX 令牌能够登录
2. AZ 登录 - 成功连接到 Azure
3. 尝试运行 az devops project list
   TF400813：用户 '1a6dbb80-5290-4fd1-a938-0ad7795dfd7a\xx.yyyy@abc.com' 无权访问此资源。

我有这个组织的完全访问权限，但仍然无法访问

在开发过程中创建了一个开发槽来部署我的机器人和单元测试，而生产/默认槽包含用于测试的实时聊天机器人的二进制文件。

• 我们成功地使用 MS Teams 频道连接到生产/默认部署槽中托管的 ChatBot。

需要输入

由于开发槽和生产/默认槽中的 ChatBot 都指向相同的MicrosoftAppId，我如何在 MS Teams 的开发槽中测试 ChatBot 二进制文件，因为MicrosoftAppId是 MS Teams Manifest 连接到 Chatbot 所需的唯一参考这两个插槽显然是相同的。

我有一个 ARM 模板代码来部署 webapp 和插槽创建以及应用程序与基于条件的相应环境。当我尝试使用模板部署资源时，它仅部署 Web 应用程序，并且未使用应用程序上的设置创建插槽。我是 ARM 的新手，任何人都可以帮我解决我的模板做错了什么。

我一直在测试 Web 应用程序的部署槽。通过将 x-ms-routing-name 附加到查询参数，您可以将调用重定向到部署槽（尽管您首先需要手动更改流量百分比才能使其工作）。

现在我正在为 Azure Functions 设置部署槽以执行相同的操作。然而，似乎 x-ms-routing-name 未被承认？我也无法更改部署槽的流量百分比，因为它们在应用服务计划中被禁用。

谁能确认 x-ms-routing-name 没有为函数实现/确认？

我有一个带有 2 个插槽（staging 和 prod）的函数应用程序，它们都会触发在同一个 blob 存储中上传文件。我的问题是：如果它们都将触发相同的 blob 存储（但行为不同），那么我将文件上传到该 blob 存储的时间将同时触发它们还是仅触发设置为主要的那个？提前致谢！

我正在尝试为我的 Azure Functions 实现自制的“API 网关”，使用代理根据查询字符串参数将请求转发到不同的部署槽：

等等等等。

我有RTFM但我仍然不知道如何正确编写路由模板来实现这一点

问：如何为这种情况配置功能代理？

Q2：有没有办法以编程方式声明这些代理配置而无需编写一堆 JSON，类似于[FunctionName]允许我在我的类中使用单个属性声明我的函数？

我通过谷歌搜索找不到任何类似的案例，但在过去的几天里我至少经历过两次。

我们针对 Web 应用程序的 DevOps 流程会删除当前插槽并创建一个新插槽，然后进行 Web 部署。

问题是在创建新插槽之后的某个时间；Web 部署任务失败，因为 Kudu 站点域没有 dns 记录：-.scm.azurewebsites.net。

当我尝试对此域 -.scm.azurewebsites.net 执行 ping 或使用全局 ping 服务时，没有 DNS 记录。

如果我们再次尝试该过程，即删除插槽并再次创建它，问题通常会消失。

有谁之前经历过这个吗？谢谢！

我们公司的网站很快将托管在 Azure 的应用服务中。该网站与同样托管在 Azure 中的 API 层进行通信，并链接到我们的内部系统和数据库。这个级别的架构此时无法更改，并且有相当多的背景历史等。

我们正在考虑在 Azure 的应用服务中使用部署槽实现始终在部署上。API 层将针对每个部署进行非破坏性更改，部署 API 将是任何版本的第一部分，随后是网站。

我们的环境之间有明确的分离，并且在生产部署开始之前，将在 Dev、Test 和 Pre-Prod 环境中对发布进行测试。总体而言，整个过程相当简单，直到涉及实施后 (PI) 测试，目前这在我们公司是强制性的。

我们需要能够在客户使用该站点之前测试生产部署。目前，我们将站点切换到维护模式，除非它是从选定的 IP 地址列表中访问的。我们现在需要在新版本的站点上执行 PI 测试，同时客户继续使用旧版本的站点。我不确定实现这一目标的最佳方法。

我确实有一个想法是有一个子域直接链接到网站 _staging 部署槽绕过部署槽设置。反过来，这里的一些逻辑可以直接进入 API _staging 部署槽。这将提供在单击“交换”按钮以交换部署槽之前发布实施更改的选项。

我知道整个过程并不理想，但目前无法更改。请问有人对上述内容有任何想法或其他建议吗？

I have a sitecore application deployed to azure webapp. It is exposed to end users through the application gateway.

There is a staging slot on the webapp and during the deployment we deploy to the staging slot, do final testing there (using azurewebsites domain) and the perform the slot swap - all the common stuff.

What is bothering us at the moment is that after the slot swap Application Gateway health probes mark the backend (with only 1 target) as unhealthy and the app goes down for about 3-5 minutes (with the "usual" 502 gateway error). We would like to avoid this, as the slot swap should not affect the performance that much.

What are the correct settings of the App Gateway to avoid this issue? Set health probe timeout to something ridiculous like 20 minutes?