ソフトウェアの既存のリリース用に複数のメンテナンス ブランチがあるとします。一部の開発者は、メンテナンス ブランチを直接変更し、定期的にトランクにマージしています。今度は、今後のメジャー リリースが予定されている、トランク コードラインの広範なリファクタリングが行われます。しかし、これにより、メンテナンス ブランチはトランク内のコードと根本的に互換性がなくなります。たとえば、もはや存在しないコードに依存する可能性があるためです。
実際には、この状況にどのように対処しますか?
2103 次
14 に答える
22
適切な変更をトランクの現在の状態にマージするのは、ブランチ メンテナンス開発者の責任だと思います。いくつかの可能性があります:
- トランク内のコードは変更されておらず、パッチは競合することなく適用されます。
- トランク内のコードが変更され、パッチが適用されますが、手動でマージする必要があります。
- トランク内のコードが完全に変更されており、パッチを適用できません。開発者は、同じ欠陥がトランクに存在するかどうかを評価し、必要に応じて同等の修正を適用する必要があります。
ケース 1 と 2 は、通常の保守開発パスです。ケース 3 は、検討中のケースで、トランク コードがいかなる形式のメンテナンス パッチも受け入れることができない場合です。開発者がトランクに同じ問題が存在するかどうかを判断できない場合は、問題追跡システムに問題を入力する必要があります。この問題により、トランクの開発者は、メンテナンス ブランチにパッチを適用する理由と、同じ欠陥がまだ存在する可能性があるかどうかを検討するようになります。トランクの欠陥の可能性について新しい問題を入力することは、メンテナンス開発者にとって最後の手段である必要があります。
メンテナンス開発者が更新されたトランクにパッチを適用しようとする利点の 1 つは、新しいコード ベースに慣れ親しむことです。最終的には、メンテナンス作業がなくなり、新しいトランクで作業する必要があります。少なくとも基本的なレベルの習熟度があると、非常に役立ちます。
于 2009-02-21T12:55:08.967 に答える
3
これは、単純な分岐/マージの質問ではなく、最終的にはチームのコミュニケーションに関する質問です。
最初のステップは、そのようなすべての場合と同様に、問題があることに気づくことです。これはあなたがやったことです。
次に、チーム全体に問題を警告する必要があります。
あなたがそれをしたら、私は2つの異なる道があると思います：
リリースされたコードがかなり成熟していてバグがないなど、メンテナンスブランチの使用頻度が低い場合は、コードのフリーズを決定できます。各開発者は、10月32日までに作業を終了し、それらの変更をトランクにマージする必要があります。その後、ブランチを閉じるか凍結する必要があります。その後、トランク内で作業を続行し、新しいソフトウェアをリリースできます。
ブランチに頻繁または緊急の変更と修正がある場合、この問題はより複雑になります。コードがフリーズする必要があります。そうしないと、トランクが何度も破壊されます。しかし、ここでは、開発者はまだ暫定的に問題を修正し、顧客に提供する必要があります。トランクコードのフリーズ後のブランチのすべての変更は、バグ追跡データベースに記録する必要があります（すべての状況で必須）。これは、ブランチNで修正されたが、まだトランクにマージされていないことを示す特別な指示があります。これには、関連するすべての詳細が記憶されるように、注意深いロギングが必要です。
トランクがリファクタリングされた後、クリーンアップ、バフ、タグ付け、リリースされる前に、バグデータベース、特にブランチで修正されたがトランクでは修正されていないアイテムを確認します。それらはまだ関連していますか？今こそ、必要に応じてコードを再度変更するときです。しばらくの間は二重の作業を意味するかもしれませんが、うまくいけば、コードは今でははるかに保守しやすくなっています。
既知の問題がすべて修正されたら、新しいバージョンをリリースし、古いブランチを閉じることができます。
于 2009-02-22T09:33:24.170 に答える
2
私が思いついた唯一の答えは、リファクタリングを開始する直前にメンテナンス トランク ブランチを作成することです。この新しいブランチをトランクのように維持し、通常どおりリリース ブランチとの間で変更をマージします。今後は、古いソース ベースと新しいソース ベースの変更を混在させることに注意する必要があります。
もう 1 つの方法は、MolhadoRef ( MolhadoRef とリファクタリング対応 SCM に関するブログ記事) のようなものを試すことです。必要に応じて、すぐに運用できる同等のシステムを見つけることができます。これは、理論的には、リファクタリング対応のソース管理です。しばらく調べていませんでしたが、最後に思い出したのは、研究論文や概念実証以上のものにはまだほど遠いものでした.
于 2009-02-21T17:55:21.103 に答える
2
実際には、新しい変更に後方互換性を持たせるために追加の作業が必要になる場合があります。
ステップ 1: コンポーネントのリファクタリングを開始します。各ステップで、古いインターフェイスを維持しますが、呼び出しを新しい実装に移行します。これは、新しいインターフェース/API が構築されるにつれて、いくつかのステップで実行できることに注意してください。単体テストでは、古いものから新しいものへの移行が正しく機能することを確認できるはずですが、この手順ではテスト/QA のオーバーヘッドが発生する可能性が高くなります。
ステップ 2: 新しいバージョンが実稼働中です。誰もがそれについて知っていることを確認してください。この時点では、新しい機能は古いバージョンに追加されておらず、すべての新しい (または変更された) 呼び出し元は新しいバージョンを使用しています。
ステップ 3: 古いインターフェースを呼び出すすべてのものを見つけ (ツールを使用してこれを行います)、新しいインターフェースを呼び出すようにすべてを変更します。これにより、おそらく多くのテスト/QA オーバーヘッドも発生します。ただし、各呼び出し元は一度に 1 つずつコミット/解放できます。
ステップ 4: この時点で、新しいバージョンはライブであり、古いバージョンにアクセスする呼び出し元は残っていません。安全に削除してください。
API が公開されていて、それを呼び出す人を制御できない場合 (たとえば、Microsoft などの企業)、ステップ #2 を通過できない可能性があることに注意してください。
このプロセスは時間がかかる可能性があり、多くの規律、コミュニケーション、およびテストが必要です。しかし、代案が永遠にキャッチアップ/統合を行う場合、それは妥当なオプションかもしれません。
于 2009-02-22T16:14:29.137 に答える
1
これは非常に作業集約的な提案かもしれませんが、私が最初に頭に浮かぶのは、すべてをトランクにマージすることです。すべての変更はトランクコピーにマージされ、すべて一緒に保持されます。次に、必要に応じてトランクをリファクタリングします。これでトランクが機能し、すべての修正がまとめられました。
残念ながら、これは、メンテナンスブランチの修正をまとめて、中央トランクにスローする必要があることを意味します。これは大変な作業になると思いますが、これによりすべてをリファクタリングできるようになり、メンテナンスブランチの改善はメインブランチに属すると思います。私はこれについてはナイーブかもしれませんが、実際には本番プロジェクトに取り組んでおらず、保守部門に何があるのか正確にもわかりません。これによりトランクが完全に更新され、メンテナンスの改善がすべてトランクに統合されると思います。
この方法で行うと、すべてのブランチの品質が最大化され、リファクタリング後に分岐するすべてのブランチにリファクタリングが分散されると思います。これは、すべてのマージでもチームをまとめるのに適した方法です。
于 2009-02-23T22:41:42.520 に答える
1
メンテナンス ブランチがメイン トランクと互換性を失った時点で、その目的のために新しいブランチを作成します。つまり、大きなプロジェクトの開始時に、すべての開発者がメイン トランクに新しい機能が追加されることを認識していることを確認して、修正を実装する場所をより適切に選択できるようにします。おそらく、メイン トランクで発生するコード変更がメンテナンスをサポートできないほど重要である場合は、メンテナンスをメイン トランクに組み込む必要があります。
于 2008-10-28T19:13:15.567 に答える
1
メンテナンス ブランチを作成し、トランクとバージョン ブランチ間のバッファとして機能させます。
バージョン ブランチへの変更はメンテナンス ブランチに送られ、可能な場合にのみトランクに伝播され、その逆も同様です。
とはいえ、特効薬はないと思います。ブランチがますます分岐するにつれて、互換性がなくなるため、それらをサポートする期間を考慮する必要があります。そうしないと、バグを複数回修正することになる可能性がありますが、さまざまなブランチでわずかに異なります。
于 2008-10-28T19:18:02.513 に答える
0
私たちのプロジェクトでは、主にバージョンメンテナンスブランチの変更を修正していません。バグがあり、
- トランクとメインブランチの両方で発生し、トランクで修正してから、変更をメンテナンスブランチにマージします（これは、クリーンに発生するか、より多くの作業が必要になる可能性があります。その場合は、新しいリリースでのみバグが修正されています）。
- それはメンテナンスブランチにのみあり、おそらくトランクに修正の王がいて、シーンナンバーワンに行きます。
于 2009-02-27T16:24:21.990 に答える
0
そんなに多くのブランチで作業する必要がありますか?
トランクの作業が開始されたのは、現在のリリースの出荷準備が整っているとプロジェクト計画で述べられていたために出荷されたからですか?
顧客が何らかの理由で最新リリースへのアップグレードを拒否しているため、多くのメンテナンス ブランチを用意していますか? その場合は、その理由を説明してください。
次のメイン リリースまでのギャップが大きすぎて、古いリリースが多すぎませんか?
コストがかかるため、メンテナンスのためにアップグレードしない顧客に料金を請求しますか?
コメントへの返信:
Vista がリリースされても、Microsoft は引き続き Windows XP をサポートしています。
非常に真実ですが、XP SP3 がリリースされたにもかかわらず、Microsoft は Windows XP SP1 をまだサポートしていません。
これは白黒ではありません。古いバージョンのサポートを停止できなくても、サポートする古いバージョンの数を減らすことができる場合があります。問題は、営業/サポートはイエスと言いがちですが、開発は苦労するので、営業/サポート担当者を味方につける必要があるということです。
于 2009-02-27T12:45:15.930 に答える
0
他の人が言ったことを繰り返すことしかできませんが、パッチキューがなり得る a$$ の本当の痛みを強調しています。
あらかじめ定義された (そして鉄壁の) マージ ウィンドウがある場合、対処する地獄は 2 週間だけです。
于 2009-02-21T13:11:29.473 に答える
0
グレッグが指摘したように、いくつかのシナリオが考えられます。
手動のマージが必要なケース (2.5) を追加しますが、メソッドを元の場所から移動してからいくつかの変更を適用したため、特に「ベース」コードも変更された場合、マージが難しくなります。 「メンテナンス」ブランチにあります。これは思ったほど珍しいことではありません。実際、メソッドを別の場所に移動し、小さな修正を適用することはよくあることです。
私たちは Xmerge (クロスマージ) と呼ばれるツールを開発しました。これは、リファクタリングを意識したマージへの第一歩です。まだ自動ではありませんが、移動されたコードを含む厳しいマージを処理するのに役立ちます。ここで説明されており、既に Plastic SCM 2.7 に統合されています。
私たちは次のことに取り組んでいます: 自動移動検出と、複数の宛先ファイルへの「クロス マージ」も可能です (コードを別のファイルに移動しますが、これもかなり一般的です)。
于 2009-04-27T22:17:07.653 に答える