2

これが理にかなっていることを願っています。これが以前に取り上げられていた場合はお詫び申し上げます。

状況: 本番環境への定期的なリリースを行っています。少なくとも 2 週間に 1 回ですが、多くの場合、1 週間に最大 3 回のリリースがあります。私たちには、3xSE、2xWD、3xQA、およびテクニカル マネージャー/リード (私) の集中チームがあります。チームは要件に応じて変動しますが、QA は通常、要件/アセットの遅延や大規模な回帰テスト フェーズに対処するために、最後に向けて大幅に規模が大きくなります。通常はリリース日をターゲットとする 6 つの標準機能ブランチと、リリース ブランチを兼ねる 1 つのトランク。マージと分岐のオーバーヘッドがありますが、これを芸術に落とし込むのはかなり上手になりました。そのため、フィーチャー ブランチの 1 つからトランクへのマージが行われるたびに、定期的にトランクからフィーチャー ブランチにマージすることでブランチを維持します。

問題: このプロセスを改善する方法を検討したいと思います。すべての作業をトランク リポジトリで行い、QA リポジトリに分岐してからリリース ブランチに分岐するオプションを検討しました。これは眉をひそめられる可能性がありますが、トランクから必要な場合は引き続き機能ブランチを使用できます。ポイントは、サイトの 2 つの主要な要素であるコンテンツと機能をまとめるには、物事を時間依存にする必要があるということです。つまり、コンテンツに時間依存性を持たせるメカニズムを提供します (機能に依存できるかどうかはわかりません)。このプロセスのコストは比較的高く、クライアントに十分な速さで対応できないため、うまくいかなかった場合はすぐにわかります。

誰か提案がありますか、または以前に同様の状況に遭遇したことがありますか?

ありがとう

4

2 に答える 2

2

SVN 1.5 を使用していますか?もしそうなら、「svn merge --reintegrate」機能を真剣に検討します。

于 2009-03-05T20:08:33.243 に答える
1

あなたが説明したシナリオに基づいています。実験的な開発をメイン トランクに移動し、リリースの機能を凍結するときにリリース ブランチを作成することをお勧めします。その時点から、バグ修正のみをリリース ブランチに導入してください。リリース ブランチは、必要なだけ残すことができます。リリースが出荷された後にブランチを削除する必要はありません。(もちろんそうしても害はありません。SVN では永久に削除されることはありません)。

于 2009-03-05T20:14:03.290 に答える