【问题标题】:Synchronizing multiple PR on multiple Gît repositories在多个 Gît 存储库上同步多个 PR
【发布时间】:2021-04-09 11:29:24
【问题描述】:

我的团队正在使用 Bitbucket Server 开发多个微服务。每个微服务都驻留在自己的存储库中。

假设您有一个营销功能,其中涉及修改 5 个微服务来实现所需的需求。开发人员必须运行 5 个 PR(每个微服务一个)。如果这些 PR 中只有 3 个没问题,你不希望他合并任何东西,但你希望他等到 5 个没问题,然后同时合并所有内容,以避免不一致。

Bitbucket 不提供这样一种场景,即人们希望拥有一个“根”PR,该 PR 依赖于每个微服务的多个子 PR。 其背后的想法是通过同步子 PR 来同时合并所有内容,一旦它们都被接受,就将它们合并一次。

我没有找到办法。 我怎样才能做到这一点?

【问题讨论】:

  • 什么是需要你这样做的用例?为什么不直接在每个存储库中提交 PR 并单独处理它们?
  • 我已经更新了我的问题以提供一个用例;-)
  • 没有很好的支持这样做的原因是它不是处理您的用例的正确方法。相反,您应该做的是测试每个微服务并将更改发布到生产环境,在功能切换之后。要真正向您的客户发布该功能,您启用功能切换,所有服务同时获得新内容。
  • 如果您依赖合并发布,只需要将其中一项服务的部署管道之一启动,您就会不同步。

标签: git git-submodules multiple-repositories


【解决方案1】:

一种方法可能是:创建一个“根项目”,其中包含所有微服务作为子模块。

对该项目的合并请求包括合并“service1 的那个版本”、“service2 的那个版本”……

【讨论】:

  • 事实上我今天还在使用子模块,而且我确实有这样一个根项目,里面有子模块。假设您在 5 个 repos 上有 5 个 PR,3 个是好的,2 个没有通过,什么会阻止某人只合并 3 个好的,然后出现不一致,因为 Microservice A v.1.0(PR 不好)不适合微服务 B v1.1(公关好)?
  • ok : 查看在合并请求上触发的钩子;你应该能够设置一个钩子,它检查你的条件是否有效,如果它失败,它会阻止合并该 MR
猜你喜欢
  • 2023-04-09
  • 1970-01-01
  • 2019-01-17
  • 2013-01-10
  • 2021-02-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-06-08
相关资源
最近更新 更多