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

Question

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

我们目前有:

每个服务和网站的多个存储库。

teamcity ci 构建，它为每个构建触发 Octopus 部署。

运行一个隔夜预定的集成测试集来测试整个平台，如果它们成功，那么所有的开发服务都会被提升到我们的夜间环境中。

从 nightly->prod 手动触发所有服务的促销。

我正在尝试在 azure devops 中做一些类似的事情，但是将许多服务/组件一起推广的概念似乎很困难，而且使用门和一些自定义搜索开放错误来阻止部署似乎有点难看。

有没有人能够建议什么是我想要实现的最佳实践？我应该有一个发布管道来从所有存储库中提取所有工件吗？

Answer 1

解释原因的详细博客文章 here

tldr…

每个微服务/可发布单元/网络前端都有一个 repo 是有意义的。

每个 repo/微服务/可发布单元/Web 前端都有一个 CI 构建，用于编译、运行大量单元测试并创建您的构建工件。如果这些单元测试中的任何一个失败，构建就会失败。

您可以为每个 CI 构建创建一个发布管道，因为如果需要，这些管道可仅用于部署单个微服务。

对于这种情况，您可以拥有一个使用来自每个 CI 构建的构建工件的发布管道。它将为所有存储库使用最新成功的 CI Build。此发布管道将有 2 个(或更多，如果您需要)阶段。每晚/测试阶段和生产阶段。每晚/测试阶段获取所有最新的成功工件并部署所有服务。在部署结束时，运行您的集成测试。如果这些通过，就会进入下一个阶段(生产)，在那里你有一个手动批准者将批准发布到生产。

所以这就是事情变得有趣的地方。如果您想遵循 Rob 当前使用的相同类型的工作流程，您可以按计划触发这个包罗万象的版本。在他的工作流程中，这个触发器似乎每晚安排一次。这确实将您的发布限制为每 24 小时最多 1 个(或您安排触发器的次数，是的，您也可以手动触发更多)。这似乎有点限制。现在，根据我的预定触发器，我的管道存在瓶颈。如果您愿意，您可以在更改构建工件时触发发布!因此，只要为每个单独的 repo 的任何 CI 构建成功构建，这将触发发布管道。这将部署到每晚/测试。运行集成测试，如果一切正常，就会进入生产阶段。