多个项目和一个解决方案-- DevOps最佳实践

Question

例如，我有一个解决方案和多个项目。基本而言，多个项目是：

• 溶液
  • REST应用程序
  • 管理UI Web应用程序
  • 共享图书馆

如果我想拥有一个用于REST和Admin的Azure DevOps管道，那么最好的方法是什么？

1. 如果解决方案中有任何变化，则触发所有内容的生成并部署两个web应用程序。
2. 每个可部署项目的CI / CD触发器；如果只在Admin中更改UI，那么只会生成相应的

我喜欢#2，我认为如果REST改变了，那么只有REST本身会触发CI / CD。如果Admin UI发生更改，则只会触发CI / CD。如果更改了共享库，则两个CI / CD触发器。

我相信这可以用路径过滤器作为触发器。但是，如果将来我有一个新的共享Library2怎么办？我需要编辑那个新项目的管道触发器。因此，我不再确定这是否是一个好的实践(可能忘记添加触发器？)

Answer 1

要回答您关于最佳实践的问题，它将以这样的方式打破部署，以尽量减少潜在的影响，同时确保合理范围内的功能，同时确保一致的集成和质量的代码流。

如果您想要保持对这两种场景的控制，我建议将这些方法结合起来。这可以通过将每个部署分解到它自己的阶段来实现，然后将该阶段与需要批准的环境联系起来。对于Dev，建议执行一张完整的CD来捕获任何可能失败的内容，然后批准您的其他环境。你的管道可能看起来是：

建造阶段：

• 构建和发布REST应用程序
• 构建和发布管理UI Web应用程序
• 建立和发布共享图书馆

部署Rest阶段开发

• 部署API的作业

部署管理UI Web

• 部署UI的作业

部署共享库阶段开发

• 部署共享库的作业

部署Rest阶段UAT..。

部署管理UI网站阶段UAT.

部署共享库阶段UAT。

对每个环境执行此模式，并配置环境审批。这将允许在每次w/o批准时在Dev中完成部署，并允许在其他环境中批准需要哪些部署。另外，如果执行多个geos/实例，则可以在该阶段的作业中调用这些数据，以允许不同组件的可伸缩性。此外，可以对作业和任务进行优化，以优化可重用性，减少复制和粘贴。

此外，如果这样做将强烈建议使用YAML模板，因为这将允许您一次性定义一个阶段所需的作业/步骤并进行重用。

下面是如何设置环境审批

下面是如何配置阶段模板