使用gerrit进行长期变革

Question

我们的项目是多模块maven项目。该项目依赖于另一个多模块maven项目。 poms（聚合和继承）的关系就像

parent-super-pom
|---parent-module-1
|---parent-module-2
|---parent-module-3
|---...
|---parent-module-n
|---child-super-pom
    |---child-module-1
    |---child-module-2
    |---child-module-3
    |---child-module-4

parent项目中的所有内容都由一个单独的小组管理，我们称之为framework。 child项目中的所有内容均由我们的团队管理，我们可以将其称为product。

现在framework已升级为使用spring-boot以及许多其他重大更改。我们需要开始开发以升级product以使用framework的最新技术。这个升级过程大约需要一个月（有许多不可编译的提交），因为需要注意很多更改才能使应用程序正常工作。与此同时，product也将在旧的maven环境中自行开发功能。处理这种情况的最佳方法是什么？

我们使用gerrit代码审查。这些变化首先在gerrit上推动，有自动jenkins作业触发器来运行基本测试。只有在构建通过时才能提交更改。还有一些构建可以根据某些触发器通过gerrit注释来执行，例如运行耗时的Web测试，集成测试等。

我的想法

  

通过 force-push 在以下上下文中我的意思是它必须   绕过gerrit，即直接推到树枝上，不   重新创建git历史的实际强制推送

• 在product中创建要升级的功能分支，例如feature/upgrade
• 确保为此分支w.r.t设置临时CI作业。新的环境，包括按需的环境
• 将更改推送到升级所需的此分支，直到应用程序可以正常运行
• 不时在master重新启动分支，以避免在升级结束时发生批量冲突（需要强制推送feature/upgrade）
• 最后，将所有更改从feature/upgrade推送到master（需要强制推送master），现在在master上配置CI作业以开始使用类似于新创建的临时工作

这个想法的缺陷是强制推动。我们确保分支机构不会受到这样的推动，因为它会使分支机构容易出错，并且组织中只有少数人可以提交此类内容。可能是我不知道我可以利用的一些细菌特征，或者我的想法是完全错误的。我需要知道处理这种情况的最佳方法是什么。

Answer 1

为什么不设置监视gerrit事件的小进程，如果将提交推送到refs/for/$your_feature_branch，则会自动将Verified标志设置为+1。您甚至可以等待Jenkins将Verified设置为该分支上的任何值，然后再将该事件集Verified设置为+1。通过这种方式，您可以保证能够独立于Jenkins中失败的构建而合并您的提交。