使用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

回答

相關問題