基本上，我正在寻找一种部署azure结构的方法，其中服务只基于版本号进行更新。
我正在通过azure devops部署一个服务结构应用程序。我写了一个脚本，它可以进行diff并更新ApplicationManifest.xml和ServiceManifest..xml上的版本号。这个脚本已经过测试，它可以正确地更新已更改服务的版本。
现在，当我尝试部署时，我得到以下错误消息：
##[error]服务清单"MyMicroServicePkg"中CodePackage名称：代码和版本：1.0.111中的内容已更改，但版本数字是一样的。
在我更新了每个包的版本之前，此错误消息一直显示在一个又一个服务上。基本上，它迫使我更新每一个包。
这是我正在使用的发布配置文件：
<?xml version="1.0" encoding="utf-8"?>
<PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
<ClusterConnectionParameters .... />
<ApplicationParameterFile Path="..ApplicationParametersPublishProfName.xml" />
<CopyPackageParameters CompressPackage="true" />
<UpgradeDeployment Mode="Monitored" Enabled="true">
<Parameters FailureAction="Rollback" Force="True" />
</UpgradeDeployment>
</PublishProfile>
以下是yaml上的devops任务：
- task: ServiceFabricDeploy@1
inputs:
publishProfilePath: $(publishProfilePath)
applicationPackagePath: $(applicationPackagePath)
serviceConnectionName: ${{ parameters.connection }}
overrideApplicationParameter: true
upgradeMode: Monitored
FailureAction: Rollback
# 30 mins timeout
UpgradeTimeoutSec: 3600
我在网上查过这个问题。一般来说，人们会讨论如何确保所有代码更改的服务都更新了版本。在我的情况下，我确信这些版本是为更改后的服务更新的。
如何配置部署，使其不进行任何代码比较，只更新具有更新版本的服务？
根据我的经验，这里的答案要点是，Service Fabric只将整个应用程序部署为每个内部包的单一版本集合，但将服务部署的细节留给您进行自定义。因此，即使您没有对该应用程序中的单个服务进行更改，最终它仍将被捆绑在部署到集群的应用程序中，并且您仍必须决定是否部署该服务(或使用提供的Deplooy-FabricInstaller.ps1脚本来处理此类部署(。
我的建议(基于我自己的管道(是，如果你真的相信你的脚本正确地检测到了更改的版本，并且你真的想避免升级你没有更改的服务(大概是为了减少部署时间(，那就改变你的方法，不要对抗应用程序部署，而是优化服务安装。
按照正常方式构建解决方案，并利用ServiceFabricUpdateManifests@2任务，让它自动替换每个服务的所有版本。
在这一点上，我通常偏离了标准管道。
- 我有一个脚本，它从ApplicationManifest.xml中删除DefaultServices以删除自动服务部署
- 我运行一个单独的脚本，检查应用程序是否已经存在(以通知它是新部署还是升级(
- 基于它是一个安装/升级，我采取了不同的部署任务路线，并捕获有关集群中现有服务的信息
应用程序完全部署后，我编写了一个类似于包含的Deploy-FabricApplication.ps1脚本的自定义脚本，该脚本遍历每个服务，并根据它们在新部署中的状态使用ServiceTemplates填充配置值来安装、升级或删除它们。
因为我控制了整个实际的服务安装过程，所以我可以根据我收集并通过构建管道传递的数据推断出应该和不应该在独立于应用程序部署的情况下实际部署什么。
你可能会发现，与你所采取的方法相比，走这条路的定制过程要容易一些。