Git 单个dotnet核心解决方案中的多个微服务&x2B；吉特回购？

我正在研究一种新的API层架构解决方案的选项。我们已经决定使用dotnet core，我们希望将应用程序功能的每个部分分解为微服务。我们使用azure devops来处理构建/测试/发布CI/CD工作流

基于广泛的分析，我估计我们当前的后端解决方案可以分为10-15个独立的微服务。不幸的是，其中大多数都会有类似的后端依赖关系，但我仍然希望将它们分开，这样我们就可以隔离单元测试，拥有更小的CI/CD足迹，并让项目从可靠的关注点分离开始

但是，同时，我希望避免使用10-15种不同的git回购协议、解决方案和CI流来简化此工作流。如果开发人员经常需要更改工作区（任何IDE中的“打开最近的”列表都会完全溢出！），维护和同步10-15 CI/CD，那么这对于开发的易用性来说就有点像噩梦了

在我看来，理想的结果是一个单一的解决方案，git repo和构建过程，每个微服务作为解决方案中的一个项目分开。当代码提交时，我想在Azure devops中启动一个进程，该进程只构建/测试/部署在提交过程中更改的服务

这是可能的还是我在做梦？我在谷歌方面运气不太好，但也许我输入的词组不对

---

提前谢谢

我们的情况大致相似，并决定将我们的微服务（不幸的是，使用共享数据库）托管在单个git repo中，但每个微服务都有自己的解决方案。每个API都有自己的构建定义，每个构建定义都有自己的带有路径过滤器的触发器。我可以想象，即使API在同一个解决方案中，这种方法也可以工作：在触发器中使用路径过滤器创建单独的构建，目标是git repo中每个API的源代码所在的文件夹。当几个API发生更改时，只有针对这些文件夹的生成才会启动。看

---

我建议您考虑一下如何跟踪发布，因为最终您将得到10-15个发布定义。单独跟踪它们（查看您在特定测试环境中运行的构建）有点麻烦，我还没有找到一种好方法来制作一个仪表板，显示部署到特定环境/阶段的所有版本。

我们在一个解决方案中对所有项目使用微服务方法（有共享项目和项目服务作为单独的服务运行）。为了实现重建唯一需要的服务的行为，我们在YAML脚本中设置了它，例如：

trigger:
  branches:
    include:
      - master
  paths:
    include:
    - MyService/*

....

steps:
- script: dotnet publish ././MyProject/MyProject.csproj --configuration $(buildConfiguration) --output $BUILD_ARTIFACTSTAGINGDIRECTORY
- task: PublishBuildArtifacts@1  

---

然后在构建之后，创建适当的工件，然后可以在部署脚本中引用。

我很高兴看到这个问题没有被关闭和标记（这是我对体系结构或“主题外”、“非代码”等问题的期望）。更不用说，还有（2）个可行的答案。