我应该在更新期间停止Azure Web App吗？

Question

我正在从Azure DevOps更新我的Azure Web应用程序。目前，我的发布是这样的：

1. 停止Web应用，
2. 更新Web应用并
3. 启动We App。

我的问题是在更新过程中停止Web App是否合理？从Azure Web App的Azure DevOps中选择发布模板时，没有任何停止/开始步骤，只有更新步骤。所以我在想甚至需要停止/启动。

Answer 1

这可能取决于您的应用程序。如果在更新应用程序时没有任何问题（例如文件正在使用中），则可以考虑使用使应用程序脱机标志，该标志将放置一个app_offline.htm文件在更新过程中位于App Service的根目录中（然后将其删除）。这样，用户将认识到应用程序正在发生某些事情。

但是，我经常最终会像您一样做：停止，更新，开始

Answer 2

我们最常做的是：

1. 停止登台时段
2. 部署到广告位
3. 起始位置
4. 切换到生产阶段
5. 停止登台时段

马丁对脱机应用的建议也是不错的选择！

我们更喜欢先部署到插槽然后再交换，这样我们对生产的影响最小，并且还可以轻松回滚。 停止/使应用程序脱机可以防止文件锁定问题。

Answer 3

同意马丁和朱纳斯。如果要在不影响用户的情况下进行部署，则需要使用插槽交换方法。 juunas也带来了轻松回滚的优点。我们的方法包括另一个称为“修补程序”的插槽。这会带来一些好处：

1. 具有一个包含生产配置的环境，因此您可以选择在实际进行交换之前进行其他测试。

2. 即使开发人员已经部署到暂存环境中，也可以回滚到产品中。

3. 允许您测试当前和以前版本的代码中的错误。有人说“在此部署之前它可以正常工作”时会很有帮助...

这就是它的样子。

Answer 4

有（5）个选项可用于 Azure Web Apps 的安全部署（原子更新）。这是我按照优先级和功能丰富程度排序的首选顺序：

1. Run-from-Package + ZipDeploy（将网站设为只读）
2. ZipDeploy（使用kudu REST api-automatically takes site offline ）
3. Azure CLI（az webapp）
4. msdeploy（-enableRule:AppOffline或stop/start site to enforce atomicity）
5. FTP（使用发布配置文件，请确保上传appoffline.htm）

还有许多其他部署选项，例如cloud sync，github continuous，本地git等-但它们都是基于Kudu API（ as is Azure CLI ）构建的。

  

注意：如果您使用的是 Azure DevOps -它几乎支持所有这些选项-leverage the Azure App Service Deploy task