リファクタリングと並行開発ブランチ

https://stackoverflow.com/questions/244439

04-07-2019
|

質問

ソフトウェアの既存のリリース用にいくつかのメンテナンスブランチがあるとします。一部の開発者は、メンテナンスブランチで直接変更を行い、定期的にトランクにマージしています。トランクのコードラインの大規模なリファクタリングが行われ、今後のメジャーリリースの予定です。しかし、これにより、たとえば、もはや存在しないコードに依存する可能性があるため、メンテナンスブランチはトランクのコードと基本的に互換性がなくなります。

実際にこの状況にどのように対処しますか？

解決

適切な変更をトランクの現在の状態にマージするのは、ブランチメンテナンス開発者の責任だと思います。いくつかの可能性があります：

トランクのコードは変更されておらず、パッチは競合することなく適用されます。
トランクのコードが変更され、パッチが適用されていますが、手動でマージする必要があります。
トランクのコードが完全に変更され、パッチを適用できません。開発者は、トランクに同じ欠陥が存在するかどうかを評価し、必要に応じて同等の修正を適用する必要があります。

ケース1および2は、通常のメンテナンス開発パスです。ケース3は、トランクコードがどのような形式のメンテナンスパッチも受け入れられない場合の検討中のケースです。開発者がトランクに同じ問題が存在する可能性があるかどうかを自分で判断できない場合、問題追跡システムに問題を入力する必要があります。この問題により、トランク開発者は、メンテナンスブランチのパッチの理由と同じ欠陥がまだ存在するかどうかを検討するように指示されます。トランクの可能性のある欠陥に新しい問題を入力することは、メンテナンス開発者にとって最後の手段です。

メンテナンス開発者に更新されたトランクにパッチを適用させてもらうことの利点の1つは、新しいコードベースの知識を増やすことです。最終的には、メンテナンス作業が不足し、新しいトランクを使用する必要があります。少なくとも基本的なレベルの親しみを持っていることは非常に有益です。

他のヒント

これは、単純な分岐/マージの質問ではなく、最終的にチームのコミュニケーションに関する質問です。

最初のステップは、このようなすべての場合と同様に、問題があることを認識することです。これはあなたがやったことです。

次に、チーム全体に問題を警告する必要があります。

一度行ったら、2つの異なるパスがあると思います：

メンテナンスブランチの使用頻度が低い場合、リリースされたコードがかなり成熟していてバグがないとしたら、コードのフリーズを決定できます。各開発者は、作業中の作業を10月32日までに完了し、それらの変更をトランクにマージする必要があります。その後、ブランチを閉じるか、凍結する必要があります。その後、トランクで作業を続行し、新しいソフトウェアをリリースできます。
ブランチで頻繁または緊急の変更と修正がある場合、この問題はより複雑です。まだコードをフリーズする必要があります。そうしないと、トランクが複数回上書きされます。しかし、ここでは、開発者はまだ暫定的に問題を修正し、顧客に提供する必要があります。トランクコードのフリーズ後のブランチのすべての変更をバグ追跡データベースに記録することをお勧めします（すべての状況で必須）。これはブランチNで修正されたが、まだトランクにマージされていないことを示します。これには、関連するすべての詳細が記憶されるように、注意深いログ記録が必要です。

トランクがリファクタリングされた後、クリーニング、バフ、タグ付け、およびリリースされる前に、特にトランクではなくブランチで修正されたアイテムのバグデータベースを確認します。それらはまだ関連していますか？ここで、必要に応じてコードを再度変更します。それはしばらくの間二重の作業を意味するかもしれませんが、願わくば、コードが今よりずっと保守しやすいことを願っています。

既知の問題がすべて修正されたら、新しいバージョンをリリースし、古いブランチを閉じることができます。

私が思いついた唯一の答えは、リファクタリングを開始する直前にメンテナンストランクブランチを作成することです。この新しいブランチをトランクのように維持し、通常どおりリリースブランチとの間で変更をマージします。今後は、古いソースベースと新しいソースベースの変更を混在させることに注意する必要があります。

他の方法は、 MolhadoRef （ MolhadoRefおよびリファクタリング対応SCMについてのブログ記事）、すぐに使用できるプロダクションが見つかった場合ニーズを満たす同等のシステム。これは、理論的には、リファクタリング対応のソース管理です。しばらく調べていませんが、最後に思い出したのは、研究論文と概念実証以外の何物でもなかったことです。

実際には、新しい変更に後方互換性を持たせるために余分な作業が必要になる場合があります。

ステップ1：コンポーネントのリファクタリングを開始します。各ステップで、古いインターフェースを保持しますが、呼び出しを新しい実装に移行します。新しいインターフェイス/ APIが構築されると、これはいくつかの手順で実行できることに注意してください。ユニットテストは、古いものから新しいものへの移行が正しく機能することを確認する必要がありますが、このステップではおそらくテスト/ QAオーバーヘッドが発生します。
ステップ2：新しいバージョンは運用中です。誰もがそれについて知っていることを確認してください。この時点では、新しい機能は古いバージョンに追加されず、すべての新しい（または変更された）呼び出し元は新しいバージョンを使用します。
ステップ3：古いインターフェイスを呼び出すすべてを見つけ（ツールを使用して）、新しいインターフェイスを呼び出すようにすべてを変更します。これには、おそらく多くのテスト/ QAオーバーヘッドも発生します。ただし、各呼び出し元は一度に1つずつコミット/リリースできます。
ステップ4：この時点で、新しいバージョンはライブであり、古いバージョンにアクセスする呼び出し元は残っていません。安全に削除します。

APIが公開されており、呼び出し元（Microsoftなどの会社）を制御していない場合は、手順2を通過できないことがあります。

このプロセスは時間がかかる場合があり、多くの訓練、コミュニケーション、およびテストが必要です。しかし、代替手段がキャッチアップ/統合を永遠に実行する場合、それは合理的なオプションかもしれません。

バグを修正するための多くのコストが問題を再現し、修正をテストすることを考えると。コードの修正をブランチごとに別々に行う必要がある場合でも、すべてのブランチで機能する自動テストを作成できますか？

メンテナンスブランチがメイントランクと互換性がなくなった時点で、その目的のために新しいブランチを作成するときが来ました。つまり、大きなプロジェクトの開始時に、すべての開発者がメイントランクに新しい機能が追加されていることを確認し、修正を実装する場所をより適切に選択できるようにします。おそらく、メイントランクで発生するコード変更が重大でメンテナンスがサポート不能になる場合、メンテナンスをメイントランクに組み込む必要があります。

メンテナンスブランチを作成し、トランクとバージョンブランチ間のバッファとして機能させます。

バージョンブランチへの変更は、メンテナンスブランチに入り、可能な場合にのみトランクに伝播します。逆も同様です。

しかし、特効薬はないと思います。ブランチがますます分岐するにつれて、ブランチの互換性がなくなるため、ブランチをサポートする期間を検討する必要があります。そうしないと、バグを複数回修正することになりますが、さまざまなブランチでわずかに異なる場合があります。

これは非常に作業集約的な提案かもしれませんが、最初に思い浮かぶのは、すべてをトランクにマージすることです。全員の変更がトランクコピーにマージされ、すべてまとめられます。次に、必要に応じてトランクをリファクタリングします。これで、すべての修正がまとめられた作業用トランクができました。

残念ながら、これは保守ブランチの修正が一緒になって中央トランクに投げ込まれる必要があることを意味します。これは非常に多くの作業になると思いますが、これによりすべてのリファクタリングが可能になり、メンテナンスブランチの改善はメインブランチに属すると思います。私はこれについて世間知らずかもしれませんが、私は実際に本番プロジェクトに取り組んでいません。これにより、トランクが完全に更新され、メンテナンスの改善がすべてトランクに統合されると思われます。

この方法で行うと、すべてのブランチの品質が最大になり、リファクタリング後にブランチするすべてのブランチにリファクタリングが広がると考えられます。これは、すべてのマージのためにチームをまとめる良い方法です。

これに取り組むには、2つの異なる方法があります：

1。

トランクへの重要な変更（主要なリファクタリングなど）は、トランクでは行わないでください。それらはブランチで行われ、十分に安定したらトランクにマージされます。

定期的に、トランクへの変更を他のメンテナンスブランチとマージする必要があります。安定しているときにのみリファクタリングをトランクにマージする理由は、これらがメンテナンスブランチにマージされるためです。ただし、これらの変更を安定させる機会がない場合は、オプション2の方が良いでしょう。

メンテナンスブランチに変更を加えた後、それらをトランクにマージして戻すことができます。

2。

保守ブランチのブランチを作成します（それぞれに1つのブランチ）。これは、トランクを各メンテナンスブランチにマージするために使用されます。（メンテナンスブランチの数を制限するには、SVN外部または同等の使用を使用する必要があります）。

トランクですべてのリファクタリングを行い、これをメンテナンスブランチのブランチにマージします。リリースするか、トランクが安定していると思う場合、メンテナンスリリースのこれらのブランチをそれぞれのブランチにマージします。次に、これらをトランクにマージして戻すことができます。

実質的に、各メンテナンスブランチは「サブトランク」になります。

このシナリオは、将来のメンテナンスと事前メンテナンスのトレードオフを強調していることに注意してください。コードにブランチと相違点が多いほど、より多くの事前保守が必要になります。良い点は、インクリメンタルメンテナンスがはるかに簡単なことです。

私は他の人が言ったことだけをエコーすることができますが、パッチキューが発生する可能性のあるa $$の本当の痛みを強調します。

事前に定義された（そして鉄で覆われた）マージウィンドウがある場合、対処すべき地獄は2週間しかありません。

最良の選択肢は、反復リファクタリングを行うことだと思います。プライベートブランチで1つの大きなショットですべてのリファクタリングを行う代わりに、一度に1フェーズずつ行います。ブランチ上でいくつかの変更セットを作成し、それらが安定していることがわかったら、それらをトランクにマージします。他のブランチで作業している開発者は、トランクを常に最新の状態に保つ責任があります。

小さな変更セットをマージすることは、かなり異なる大きなブランチをマージすることよりも、非常に頻繁に機能しなくなります。頻繁にマージするほど、最終的に必要な作業は少なくなります。

このプロジェクトでは、主にバージョンメンテナンスブランチの変更を修正しません。バグがある場合

これは、トランクとメインブランチの両方で発生し、トランクで修正してから、メンテナンスブランチに変更をマージします（これは、さらにきれいに行われるか、より多くの作業が必要な場合があります。バグを新しいリリースでのみ修正することをお勧めします。）
メンテナンスブランチにのみ存在します。おそらくトランクに修正の王様がいるので、シーン1に進みます。

作業中の多くのブランチを持っている必要がありますか？

トランクの作業は、プロジェクト計画で現在のリリースの出荷準備が整ったため、出荷されたために開始されたときにのみ開始されましたか？

顧客が何らかの理由で最新リリースへのアップグレードを拒否しているため、多くのメンテナンスブランチがありますか？その場合、理由に対処します。

次のメインリリースが大きくなる前にギャップが生じたため、古いリリースが多すぎますか？

費用がかかるため、メンテナンスのためにアップグレードしない顧客に請求しますか？

コメントへの応答：

Microsoftは引き続きWindows XPをサポートしています Vistaが出ていても

本当ですが、MicrosoftはXP SP3がリリースされていてもWindow XP SP1をまだサポートしていません。

これは白黒ではありません。古いバージョンのサポートをやめられなくても、サポートする古いバージョンの数を減らすことができる場合があります。問題は、セールス/サポートが「はい」と言うのを好むことですが、開発には苦痛が伴うため、セールス/サポート担当者を味方につける必要があります。

Gregが指摘したように、いくつかの可能なシナリオがあります。 p>

手動マージが必要なケース（2.5）を追加しますが、メソッドを元の場所から移動してからいくつかの変更を適用したため、特に「ベース」がコードは＆quot; maintenance＆quot;でも変更されました。ブランチ。これは見た目ほど珍しいことではありません。実際、メソッドを別の場所に移動して小さな修正を適用することは非常に一般的です。

リファクタリング対応のマージに向けた最初のステップであるXmerge（クロスマージ）と呼ばれるツールを開発しました。まだ自動ではありませんが、移動されたコードに関連する厳しいマージの処理に役立ちます。ここに記載され、すでに統合されていますプラスチックSCM 2.7。

現在取り組んでいるのは、自動移動検出であり、「クロスマージ」も可能です。複数の宛先ファイルに向けて（コードを別のファイルに移動しますが、これも非常に一般的です）。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow