version-control - リファクタリングとマージの必要性の間の緊張をどのように処理しますか?

Question

新しいバージョンを提供するときのポリシーは、VCS にブランチを作成し、QA チームに処理させることです。後者がゴーサインを出したら、タグを付けて製品をリリースします。テクニカル リリースを作成できるように、ブランチはバグ修正 (のみ) を受信するために保持されます。これらのバグ修正は、その後トランクにマージされます。

この間、トランクは主要な開発作業を見ており、リファクタリングの変更を受ける可能性があります。

問題は、(バグ修正のマージが成功するように) 安定したトランクを持つ必要性と、コードが別のメソッドに抽出された場合や別のクラスに移動された場合、通常はできないこととの間に緊張関係があることです。新しい機能を導入するときにリファクタリングする必要性。

私たちのポリシーは、十分な時間が経過してブランチが十分に安定するまでリファクタリングを行わないことです。この場合、トランクで変更のリファクタリングを開始でき、トランクとブランチの両方でバグ修正を手動でコミットする必要があります。

しかし、これは、開発者がトランクにリファクタリングの変更をコミットする前に、かなりの時間を待たなければならないことを意味します。これは、ブランチからトランクへの後続のマージを中断する可能性があるためです。また、バグをブランチからトランクに手動で移植しなければならないのは苦痛です。これは開発を妨げているように私には思えます...

この緊張をどのように処理しますか？

ありがとう。

Answer 1

これは現実的な問題です。サポートする必要のある複数のバージョンがあり、それぞれに分岐している場合はさらに悪化します。本物の R&D ブランチも持っていると、さらに悪いことになります。

リリースのタイミングが商業的に重要な環境では、コードを安定させるべきだと主張することはできなかったので、メイン トランクを通常の速度で進行させ、保持しないことを好みました ("つまり、あなたは不安定な状態でリリースした？」）。

重要なのは、バグ修正のために作成された単体テストが、バグがメイン ブランチに移行されたときに移行されることを確認することでした。新しいコードの変更が純粋にリファクタリングである場合は、古いテストも同様に機能するはずです。変更が有効でなくなるようなものである場合、どのような場合でも修正を移植することはできず、誰かに新しいコード ストリームの修正についてよく考えてもらう必要があります。

この種の問題を数年間管理してきた結果、適切なサポートとカバレッジを提供するには、少なくとも 4 つのコード ストリームが必要であり、それら全体のコードを管理するためのかなり厳密なプロセスのコレクションが必要であるという結論に達しました。これは、どんな地図でも 4 色で描ける問題に少し似ています。

私は、この主題に関する本当に優れた文献を見つけたことがありません。それは必然的に、リリース戦略と、顧客と署名する SLA に結び付けられます。

補遺: ブランチのマージを特定のマイルストーンとして、メイン ブランチのリリース スケジュールに書き込む必要があったことも言及しておく必要があります。機能を実装する仕事をしている勤勉な開発者のコ​​レクションがある場合、ブランチをまとめるために必要な作業量を過小評価しないでください。

Answer 2

私が働いている場所では、重要な変更 (機能の追加やバグ修正) ごとに、一時的な短命 (1 日未満 -- 数週間) の作業ブランチを作成します。トランクは安定しており、(理想的には) いつでも解放できる可能性があります。完了した項目のみがマージされます。トランクからコミットされたものはすべて、毎日作業ブランチにマージされます。これは大部分が自動化できます (Hudson、Ant、および Subversion を使用しています)。(もちろん、競合は遅かれ早かれ解決する方がよいため、この最後の点です。)

私たちが現在使用しているモデルは、Henrik Kniberg による優れた記事 (以前にプラグインしたもの) の影響を大きく受けています:複数のアジャイル チームのバージョン管理。

(私たちの場合、2 つのスクラム チームが 1 つのコードベースで作業していますが、このモデルは 1 つのチームでも有益であると考えるようになりました。)

svn merge --reintegrate追加の分岐とマージにはいくらかのオーバーヘッドがありますが、慣れてツールを使いこなすと (たとえば、便利です) 、実際にはそれほど多くはありません。いいえ、一時ブランチを常に作成するわけではありません。たとえば、トランクへの 1 回のコミットで簡単に完了することができる、小規模でリスクの低いリファクタリング (現在作業中の主要な項目とは無関係) の場合です。

また、重大なバグが随時修正される古いリリース ブランチも維持しています。確かに、コードの特定の部分がブランチと比較してトランクで大幅に進化した場合、手動の (時には面倒な) マージ作業が発生する可能性があります。(これは、trunk から (内部的に) 継続的にインクリメントをリリースし、マーケティングと製品管理が外部リリースをいつ行うかを決定できるようになるにつれて、問題が少なくなることを願っています。)

これがあなたの質問に直接答えているのか、それともあなたの環境 (別の QA チームなど) にこれを適用できるのかどうかはわかりませんが、少なくとも、あなたが説明する緊張は私たちには存在せず、私たちはいつでも自由にリファクタリングできます。幸運を！

Answer 3

たぶん、Git（または他のDVCS）は、ファイルを比較するだけでなく、（実際に）変更を管理するという事実のおかげで、更新されたコードへのマージの処理に優れています... Joelが言うように：

分散バージョン管理を使用すると、マージが簡単になり、正常に機能します。したがって、実際に安定したブランチと開発ブランチを作成したり、QAチームが展開前にテストを行うための長期的なブランチを作成したり、短期間のブランチを作成して新しいアイデアを試したり、それらがどのように機能するかを確認したりできます。

まだ試していませんが...

Answer 4

開発プロセスに次の要素を追加することで、緊張に対処できると思います。

1. 継続的インテグレーション
2. 自動機能テスト（ユニットテストですでに数えていると思います）
3. 自動配信

継続的インテグレーションでは、すべてのコミットは、すべての単体テストが実行され、問題が発生した場合に警告が発せられるビルドを意味します。あなたは頭でより多くの作業を開始し、コードベースを分岐する傾向が少なくなります。

自動化された機能テストを使用すると、ボタンをクリックするだけでアプリケーションをテストできます。通常、これらのテストには時間がかかるため、これらは毎晩実行されます。これにより、バージョニングの古典的な役割は重要性を失い始めます。バージョンとその成熟度に基づいてリリースする時期を決定するのではなく、ビジネス上の決定になります。ユニットテストと機能テストを実装していて、チームがテスト済みのコードを送信している場合、ヘッドは常にリリース可能な状態になっている必要があります。バグは継続的に発見され、修正されてリリースされますが、これはもはや循環的なプロセスではなく、継続的なプロセスです。

これは、根強い慣習を変えることを意味するため、おそらく2種類の批判者がいるでしょう。まず、継続的デリバリーのパラダイムシフトは、マネージャーにとって直感に反しているように見えます。「大きなバグを出荷するリスクはありませんか？」LinuxまたはWindowsディストリビューションを見ると、これはまさに彼らが行っていることです。つまり、リリースを顧客に向けてプッシュすることです。また、一連の自動テストを使用することで、危険性がさらに軽減されます。

次に、QAチームまたは部門。（問題はそれ自体の存在であると主張する人もいます！）彼らは一般的にテストの自動化を嫌います。それは、新しく、時には複雑なツールを学ぶことを意味します。ここでは、それを行うことによって説教するのが最善です。私たちの開発チームは継続的インテグレーションに取り組み始め、同時にSeleniumを使用して一連の機能テストを作成しました。QAチームがツールの動作を確認したとき、その実装に反対することは困難でした。

最後に、私が説明したプロセスは、開発プロセスに3つの要素を追加するほど単純ではないということです。これは、ソフトウェアの開発方法に大きな変化があることを意味します。

Answer 5

おそらく、私たちの問題は、非常に長い寿命 (最大 18 か月) を持つ必要があるブランチがあり、それらに対して実行する必要がある多くの修正があるという事実に起因しています。

非常に安定したコードからのみ分岐するようにすることはおそらく役立つでしょうが、それほど簡単ではありません... :(

Answer 6

私が働いている場所では、メインブランチでリファクタリングを続けています。マージが複雑になった場合は、その場しのぎで処理する必要があります。すべて実行可能ですが、少し時間がかかる場合があります。