升级后 Azure 服务结构持续部署和回滚选项答案

【问题标题】：Azure service fabric continuous deployment and rollback options after upgrade升级后 Azure 服务结构持续部署和回滚选项
【发布时间】：2018-07-23 23:45:41
【问题描述】：

我阅读了有关使用 VSTS 持续部署服务结构的文章。在这种情况下，我需要帮助/建议

我在 Azure 中通过持续部署部署了一组服务
现在我升级了一项服务，我知道当这次升级失败时，服务结构会回滚到之前的状态。让我们假设升级成功，现在我运行集成测试（作为构建定义管道的一部分）并且它失败了，在这种情况下如何单独回滚这个特定服务，以便其他服务不受影响并且回滚应该是自动化的，不应有任何人工干预

示例： -

推送你的代码
升级服务A where group的部署服务正在运行
执行集成测试
失败，回滚服务升级A，成功，继续升级其他节点

这可以在 VSTS 中实现完全自动化吗？

我参考了这个链接：https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-upgrade#rolling-upgrades-overview

【问题讨论】：

标签： azure azure-service-fabric continuous-deployment azure-pipelines-release-pipeline

【解决方案1】：

回滚 API 只能用于回滚当前正在进行的升级到新版本，您可以通过 API 回滚已完成的升级，因此您不能在 VSTS 构建/发布中这样做。

基于此线程：Staging slot and vip-swap，您可以为新的应用程序版本创建实例。

【讨论】：

【解决方案2】：

您可以使用内置服务health monitoring。通过实施自定义健康监视器（运行您的集成测试），您可以在升级过程中失败时报告“不健康”。您可以使用此信息让 SF 自动回滚升级。（通过配置健康阈值。）您还可以手动控制升级，例如使用 PowerShell Start-ServiceFabricApplicationUpgrade。

Scott Hanselman 对此进行了很好的演示here。另一个例子here。

【讨论】：

感谢您的快速回答，自定义健康检查可以包括功能测试用例吗？
您可以使用（任何）代码来检查事物，并使用结果来填充健康报告对象，例如DeployedServicePackageHealthReport。（没有专门的测试运行器）
@LoekD，但是在第 2 步完成后（新包的成功部署），SF 是否有可能进入下一个更新域并且新代码可以在健康检查（集成测试）是否已完成？或者升级是否可以指定一些健康检查必须在升级被认为“完成”之前通过？
在移动到下一个升级域之前执行健康检查。您指定您的平台对不健康的容忍程度。 docs.microsoft.com/en-us/azure/service-fabric/…
感谢@LoekD 提供的信息。您引用的页面将我带到了this page，它更多地解释了升级过程并讨论了健康检查。