如何最好地将Azure Devops发布管道与微服务结合使用？

Question

我正在将微服务ci / cd管道从teamcity + octopus设置迁移到Azure Devops。

我们目前有：

• 每个服务和网站都有多个存储库。
• teamcity ci构建，可为每个构建触发章鱼部署。
• 运行了一整夜的预定集成测试来测试整个平台，如果它们成功了，那么所有开发服务都会升级到我们的夜间环境。
• 手动触发的每晚->产品促销。

我正在尝试在天蓝色的开发者中做类似的事情，但是使用门和一些自定义搜索未解决的bug来阻止部署的共同推广许多服务/组件的概念似乎很困难并且有点丑陋。

有人能建议我要达到的最佳实践吗？我应该有一个单一的发布管道来从所有存储库中提取所有工件吗？

Answer 1

详细的博客文章，解释了为什么here

tldr ...

• 每个微服务/可发布单元/ Web前端都有一个存储库很有意义。
• 每个回购/微服务/可发布的单元/ Web前端都有一个CI构建，该CI构建可以编译，运行大量的单元测试并创建您的构建工件。如果这些单元测试中的任何一个失败，则构建将失败。
• 您可以为每个CI Build都有一个发布管道，因为如果需要，这些管道可用于仅部署单个微服务。
• 对于这种情况，您可以拥有一个发布管道，该管道使用每个CI构建中的构建工件。它将对所有存储库使用最新成功的CI Build。该发布管道将具有2个（或更多，如果需要的话）阶段。每晚/测试阶段和生产阶段。每晚/测试阶段将获取所有最新成功的工件，并部署所有服务。在部署结束时，运行集成测试。如果这些通过，则转到下一个阶段（产品），在此阶段，您有一个手动批准者，该批准者将正式发布产品。
• 这就是有趣的地方。如果您希望遵循与Rob当前使用的相同类型的工作流，则可以按计划触发此全面的版本。在他的工作流程中，此触发器似乎是每晚安排一次。这确实将您的发布限制为每24小时最多1次发布（或安排触发次数的次数，是的，您也可以手动触发更多次）。这似乎有点限制性。现在，基于计划的触发器，我的管道遇到了瓶颈。如果需要，您可以在对构建工件进行更改时触发发布！因此，只要每个单独的回购都成功构建了任何CI构建，就会触发发布管道。它将部署到每晚/测试。运行集成测试，如果一切看起来不错，则进入生产阶段。