11

Web アプリケーション プロジェクトの最適な分岐戦略を決定しようとしています。これが私がこれまでに思いついたことです。コメントや経験をいただければ幸いです。

私の見方では、「リリースによる分岐」と「機能による分岐」という 2 つの主要な分岐戦略があります。

"Branch by release" : 開発はトランク上で行われます。リリースの時期が近づくと、そのリリース用のブランチが作成されます。その後、このブランチは安定化/テストされ、最終的にリリースされます。リリース後、ブランチはトランクにマージされますが、バグ修正のためにリリース ブランチは維持されます。バグ修正が適用されている場合は、トランクにマージされます (トランクの開発が他の方法でバグを覆い隠していない場合)。新機能はトランクに追加され、リリース ブランチには影響しません。新しいリリース時期が近づくと、新しいリリース ブランチが作成されます。

"Branch by feature" : トランクは常に "production" トランク (ライブのコード) です。バグ修正はトランクに直接コミットされます。次のリリースの機能は機能ブランチで開発されます。バグ修正は時々機能ブランチにマージされます。リリース時期になると、フィーチャー ブランチはトランクにマージされ、ライフ サイクルが継続します。

これら 2 つの戦略の実際的な大きな違いは、「リリースごとに」ソフトウェアのさまざまな製品バージョンを維持できることです (クライアント A がバージョン 1 でクライアント B がバージョン 1.5 の場合、クライアントはこれで有料の顧客です)。場合）。対照的に、「機能別」戦略を使用すると、現在の製品バージョンのみをサポートできます (すべてのクライアントが最新バージョンを使用しています)。

典型的なWeb アプリケーションでは、すべてのクライアントが同じ「最新」バージョンを使用しているため (すべて同じサーバーにアクセスするため)、「機能ごと」のアプローチが最も一般的に使用されていると思います。3 つのリリース バージョンすべてにバグ修正を適用する必要がある場合など、「階層全体」でマージする必要がなくなります。

したがって、私の現在のステータスは、「機能ごとに分岐」する必要があるということです。それが問題なら、私のチームはあまり熟練していません。

4

5 に答える 5

5

常に 1 つのリリースのみを公開し、すべての開発を 1 つの機能ブランチで行う場合、これらのアプローチは事実上同じです。

機能ごとに分岐することが、一度に複数の分岐を実行することを意味する場合、疫病のようにそれを避けます。ブランチが増えるということは、それ自体が苦痛であるマージが増えることを意味し、統合地獄が増えることを意味します。単一のコードラインに継続的インテグレーションを行う方がはるかに優れています。

デプロイ プロセスが、ブランチ、テスト、稼働よりも複雑な場合、リリースごとのブランチの利点は、さまざまなフェーズで複数のリリース ブランチを一度に作成できることです。もう 1 つは安定化、テスト、受け入れなどを経ており、開発はトランクで継続されています。一方、ライブ トランクを使用している場合、機能ブランチをマージしてライブに移行すると、現在のライブ システムにバグ修正を行うことができなくなります。フィーチャー ブランチのマージは後戻りできなくなります。

于 2010-12-22T14:57:37.300 に答える
5

どのようなソフトウェアを開発していますか? 収縮包装？オープンソース プロジェクト? その場合は、「リリースによるブランチ」または「不安定なトランク」アプローチを使用してください。特に、リリース サイクルが 6 か月から 1 年おきの場合はなおさらです。

ただし、数週間に 1 回またはそれ以下など、より短い頻度で変更が行われる Web ベースのプロジェクトを維持している場合は、「機能ごとに分岐」または「安定したトランク」アプローチを使用してください。このアプローチの問題点は、大幅な変更を伴う複数の機能変更を統合すると、マージ プロセスが面白くなくなることです。本当に難しくなります。

しかし、どちらもうまく機能しますが、両方が必要な場合はどうでしょうか? つまり、2 週間に 1 回デプロイして大きな機能変更を行うプロジェクトがありますが、これらの機能変更の準備が整うまで待てないバグ修正が多数あることがわかりました。トランクは、「機能ごとのブランチ」アプローチのリリース ブランチです。リリースと機能の両方を独自のブランチで取得できるとしたら?

CollabNet の Bob Archer によるこのブログ エントリをご覧ください。彼のアジャイル リリース戦略は、両方の長所を提供します。私はこれを使用しました。非常に柔軟です。Bob の図には示されていませんが、複数のリリース ブランチを同時に進行させることができます。これは、本番環境へのロールアウトの準備ができている 1 つのリリース ブランチと、最終的な QA チェックのために準備されている別のリリース ブランチを持つことができることを意味します。ただし、次の 2 つの点を考慮する必要があります。

まず、あなたの開発者はどれくらいうまくマージできていますか? 小規模なチームであっても、アジャイル リリース戦略アプローチを自分で行うことはできません。誰もが自分の役割を果たさなければならず、マージと、マージを行うために使用するツールを本当に理解する必要があります。

第二に、準備ができている変更とこれから行われる変更をよく把握する必要があります。リリース管理は、これを時計のように機能させるための鍵です。準備ができたら、各機能をリリース ブランチに割り当ててマージする必要があります。

どのアプローチを選択するにせよ、最終的には、何を開発しているか、およびその開発のためにリリースする変更の頻度に依存します。

于 2010-12-22T15:12:45.940 に答える
2

これらの選択肢は相互に排他的ではありません。両方を使用してください。 それらはさまざまな問題を解決します。

「リリースごとのブランチ」 - リリース ブランチは、次のバージョンの開発中に、現在のライブ バージョン (または以前にリリースされたバージョン) を生成するために使用されたソースに戻ることができるようにするために使用されます。たとえば、これは、現在の開発トランクからバグ修正またはバックパッチ機能のリリース バージョンに変更を加えるためです。

「機能ごとに分岐」 - 常に安定した開発トランクを維持するために使用されます。これは、複数の開発者や実験的な「おそらく」機能に特に役立ちます。

私は両方を使用しますが、解決する問題が自分に当てはまらない場合、またはその問題に別の解決策がある場合は、いずれかのアプローチを放棄できます。

git や Mercurial などの最新の DVCS を使用することを強くお勧めします。それらは並行開発を対象としているため、古いシステムとは異なる方法で変更を保存するため、マージがより適切になります。

于 2010-12-22T15:10:09.327 に答える
2

さらに混乱するリスクがあります: リリース ブランチを持ち、フィーチャー ブランチですべての変更を行うことができます。これらは相互に排他的ではありません。

そうは言っても、並行リリース ファミリーは必要なく、頻繁に、場合によっては継続的に展開したいと考えているようです。そのため、いつでも解放できる「安定したトランク」が必要になります。機能ブランチは、変更が完了し、それ自体が証明されたときにのみトランクにマージするため、トランクの安定性を維持するのに役立ちます。

したがって、あなたの選択は適切であると言えます。

于 2010-12-22T15:11:46.597 に答える
1

私は自分のプロジェクトに Git を使用する傾向がありますが、従う傾向があるプロセスは次のようになります (Subversion でも同様に機能するはずです)。

  • 新しい機能ごとに、その機能のブランチを作成します。
  • すべてが機能したら、それをブランチにマージしstaging、ステージング サーバーにデプロイします (それらのいずれかを持っていますよね?)
  • クライアントがステージングの内容に満足していることを確認したら、ステージング ブランチをプロダクション ブランチにマージし、production_release_22またはproduction_release_new_feature_xなどのタグを付けてから、そのタグをプロダクション サーバーにデプロイします。

タグが更新されることはありません。一度何かがデプロイされると、さらに変更がビルド、テスト、タグ付けされるまでその状態が維持されます。その後、新しいタグがデプロイされます。ブランチではなくタグがデプロイされていることを確認することで、「この1つの簡単な変更をコミットして、テストせずにサーバーを更新する」などのことを自分自身（または他の人）がしないようにします。

これまでのところ、私にとってはかなりうまくいっています。

于 2010-12-22T14:59:57.040 に答える