使用gerrit的long rebase

我们的项目是多模块maven项目。该项目依赖于另一个多模块maven项目。 POMS的关系（包括聚合和继承方式）像使用gerrit的long rebase

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工作触发器来运行基本测试。只有构建通过时才能提交更改。也有建立可根据通过格里特评论一些触发器被要求要运行耗时网络测试，集成测试等

我的想法

通过力推动在下面的方面，我的意思是，它已经到旁路格里特即直接推送到分支不的实际力量推动，再现历史的git

创建product升级特性分支，说feature/upgrade
确保临时CI的工作是建立这个分公司w.r.t.新的环境，包括点播那些
更改推到这个分支升级所需直到应用程序可以正常运行
从时间调整基线上master分支时间，以避免在升级结束批量冲突（需要在feature/upgrade力推送）
最后，推动所有的变化从feature/upgrade到master（将要求master力推），现在在主配置CI工作开始使用新创建的临时职位

此id的缺陷ea是力量推动。我们确保分支机构不会受到这种推动，因为分支机构容易犯错误，组织中只有少数人可以提交此类提交。可能是我不知道我可以在这里使用的一些gerrit功能，或者我的想法是完全错误的。我需要知道处理这种情况的最佳方法是什么。

来源

2017-12-18 Mukund

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

来源

2017-12-18 17:01:48 Dmitri

我不希望发生这种情况。我想要提交验证。我最终想避免的是通过绕过gerrit来重塑。 – Mukund

使用gerrit的long rebase

回答

相关问题