我的问题是与this question有些相似，但答案对我没有帮助，除非我遗漏了什么。
如果我想将10+无状态服务（基于OWIN的Web API）部署到Service Fabric集群中，那么根据我对ASF的理解，我会：
但这不会涉及在与Service Fabric应用程序相同的Visual Studio解决方案中创建所有Web API吗？
我担心的是，如果我们希望团队完全自治，理想情况下他们不需要共享相同的Visual Studio解决方案？
目前，每个“团队”都有自己的GitHub存储库和Visual Studio解决方案，每个API都是独立部署的。
我希望将此设置移植到ASF，其中每个Web API都是它自己的解决方案，并且它们以某种方式打包到一个Service Fabric应用程序中。
任何人都可以帮我这个吗？
由于
答案 0 :(得分：2)
我将每个服务保留在自己的解决方案（和repo）中，并且只在部署时将所有内容整合到一个应用程序中。通过PowerShell进行构建和部署，可以作为CI / CD过程的一部分进行触发。只修改了更新的服务，并使用当前日期/时间自动更新清单版本。
对于具有其他服务依赖性的服务，我在解决方案中引用了他们的项目，因此我可以轻松调试，但只部署了主服务。
在答案中添加更多细节，评论区块太小。
我创建了一个目录，将发布版本放在正确的SF目录结构中。我将发布的ApplicationManifest.xml复制到该目录，尽管你可以将它作为一个repo并检查该文件。我有一个buildrelease.ps1枚举repos并运行msbuild用于发布配置。对于该配置，我不构建除要部署的服务之外的任何东西（没有用于调试目的的单元测试或其他测试应用程序）。该版本是根据日期和时间自动生成的，例如2017_05_31_1702。这是在服务清单中更新的内容，最终在应用程序清单中更新。成功构建后，服务清单将更新回到解决方案目录中，如下所示：
$serviceManifestPath = "$solutionDir\src\${ServiceName}Service\PackageRoot\ServiceManifest.xml"
Set-ItemProperty $serviceManifestPath -name IsReadOnly -value $false
$serviceManifestXml = [xml](Get-Content $serviceManifestPath)
$ns = New-Object System.Xml.XmlNamespaceManager($serviceManifestXml.NameTable)
$ns.AddNamespace("ns", $serviceManifestXml.DocumentElement.NamespaceURI)
$serviceManifestXml.ServiceManifest.Version = $NewVersion
$serviceManifestXml.ServiceManifest.CodePackage.Version = $NewVersion
$serviceManifestXml.ServiceManifest.ConfigPackage.Version = $NewVersion
$serviceManifestXml.Save($serviceManifestPath)
再次调用下一个msbuild来打包SFProj。
$buildResult = & $msBuild $sfproj /p:Configuration=Release /nologo /v:M /fl /flp:LogFile="msbuild.log;Verbosity=Normal" /nr:false /target:package
今天我只构建具有已修改服务清单的服务，因此您必须记住在修改代码/配置时修改清单。我想改善这一点，但时间不够。
打包后，解决方案的发布{service name} Service.pkg将复制到release文件夹中。脚本完成后，生成的目录包含正确格式的任何已更改服务。
下一个脚本是每个群集的部署脚本。我确信可以创建一个数据驱动的。这将连接到远程群集，测试程序包，将程序包上载到映像存储并执行新的或升级，具体取决于应用程序是否已存在。我有一个可以部署到我的one-box的版本，所以我可以测试/调试所有使用本地配置一起运行的服务。