gerritを使用した長いrebase

Question

私たちのプロジェクトは、マルチモジュールプロジェクトです。このプロジェクトは別のマルチモジュールプロジェクトに依存しています。 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を使用するようにアップグレードされており、他にも多くの変更点があります。 frameworkの最新の技術を使用するには、productをアップグレードする開発を開始する必要があります。このアップグレードプロセスは、アプリケーションを動作させるために必要な変更がたくさんあるため、（コンパイル不可能なコミットが多数の）約1ヶ月かかるでしょう。一方で、productも古いMaven環境で独自の機能を開発しています。この状況に近づく最善の方法は何でしょうか？

私たちはジェリーコードレビューを使用しています。変更は最初にgerritにプッシュされ、基本テストを実行するための自動ジンキンジョブトリガーがあります。変更はビルドが合格した場合にのみ提出することができます。また、など

私の考え

力プッシュ中では、ウェブテスト、統合テスト時間のかかるを実行したいとヘリットコメントを通していくつかのトリガーに基づいて要求することができござい構築していますそれは バイパスヘリット、すなわちへの分岐やGitの歴史に

012を再現 ない 実際の力プッシュに直接プッシュしていることを私が意味する、以下のコンテキスト

• feature/upgrade
• は必ず一時的なCIの仕事は、この分岐w.r.t.のためのセットアップであることを確認してくださいと言う、アップグレードのためにproductに機能ブランチを作成します。アプリケーションが正常
• 実行できるようになるまで、オンデマンドのものアップグレードに必要なこのブランチへ
• プッシュ変更を含む新しい環境では、アップグレードの終了時に大量の競合を避けるために随時masterのブランチをリベース（必要になりますfeature/upgrade上の力プッシュ）終わり
• は、新しく作成された一時的な雇用
のと同様の設定を使用して起動する masterに力押しを必要）となりましマスターにCIジョブを構成します（ feature/upgradeから masterに対するすべての変更をプッシュ

このIDの瑕疵eaは強制押しです。私たちは支店がミスに脆弱になり、組織内の少数の人しかそのような提出をすることができないように、支店がそのようなプッシュに対してロックされていることを保証します。私がここで活用したり、私のアイデアが完全に間違っているかもしれないいくつかのgerrit機能を知らないかもしれません。私はそのような状況に対処する最良のアプローチが何であるかを知る必要があります。

Answer 1

gerritイベントを監視する小さなプロセスを設定し、コミットがrefs/for/$your_feature_branchにプッシュされると、自動的にVerifiedフラグが+1に設定されます。 Verifiedにブランチの値を設定してから、そのイベントに基づいてVerifiedを再度+1するまで待つこともできます。このようにして、Jenkinsで失敗したビルドとは独立して、あなたがマージできることが保証されます。