ソースコードとアプリケーションライフサイクルの分岐に関するベストプラクティス

私たちは小さなISVショップであり、通常、毎月新しいバージョンの製品を出荷しています。コードリポジトリとしてSubversionを、IDEとしてVisual Studio 2010を使用しています。多くの人々がMercurialやその他の分散ソース管理システムを主張していることは承知していますが、現時点では、これらのメリットをどのように享受できるかわかりませんが、私は間違っているかもしれません。

私たちの主な問題は、ブランチとメイントランクを同期させる方法です。

これが今日のやり方です。

1. 新しいバージョンをリリース（Subversionでタグを自動的に作成）
2. 来月リリースされるメイントランクの作業を続けます

そしてこのサイクルは毎月繰り返され、完璧に機能します。この問題は、緊急のサービスリリースをリリースする必要がある場合に発生します。メイントランクから解放することはできません（2）。開発中のため、緊急に解放するのに十分な安定性がないためです。

このような場合、次のことを行います。

1. 手順（1）で作成したタグからブランチを作成します
2. バグ修正
3. テストとリリース
4. 変更をメイントランクにプッシュします（該当する場合）。

私たちの最大の問題は、これら2つをマージすることです（ブランチとメイン）。ほとんどの場合、次の理由により、自動マージに依存できません。

• メイントランクに多くの変更が加えられました
• 複雑なファイル（Visual Studio XMLファイルなど）のマージがうまく機能しない
• 別の開発者/チームが理解できない変更を加えたため、マージできない

したがって、これら2つの異なるバージョン（ブランチとメイン）を同期させるためのベストプラクティスは、あなたが考えることです。職業はなんですか？

ブランチとマージへのアプローチは大丈夫だと思いますが、主な問題がコードベースが非常に不安定である場合は、それを集中して最小化する必要があります。

確認する最も重要なことは、コードベースが問題を適切に分離していることです。さまざまなコンポーネント間の依存関係を分離して削減する必要があります。これで問題の大部分が解決されます。また、単一責任原則などの以下の慣行が役立ちます。

大きなアーキテクチャの変更を行う必要がある場合は、独自のブランチで行い、完全にテストされて（妥当な範囲内で）安定したらメインにマージする必要があります。これは苦痛でやりがいのあることかもしれませんが、それもまれなはずです。適切なテストを実施していれば、リスクは最小限に抑えられます。

また、分散バージョン管理システムに変更すると役立つ場合があります。これにより、安定したトランクが提供され、準備が整うと、さまざまな機能がさまざまなブランチからマージされます。コードの相互依存が強すぎる場合でも、マージの問題は発生しますが、より細かく制御できます。

これを別の視点から見て、チーム間のコミュニケーションを増やすことも検討してください。定期的にアジャイルスタイルのスタンドアップミーティングを実行します。チームメンバーが座っている場所と、それがどのように役立つかを検討します。複雑なマージを実行する必要がある場合、それはそれほど悪いことではない可能性があります。両方の当事者が理解できるペアプログラミングアプローチを使用してください。

私はそれをほとんど反対の方向から見る傾向があります：

• Trunkは常に本番対応のコードである必要があります（最初の最初のリリース後）。
• 毎月の開発が行われるトランクと並行して実行される開発タイプのブランチがあるはずです。毎月リリース時間になると、これはトランクにマージされ、テストされてからリリースされます。
• 修正プログラムはトランクで簡単に作成およびチェックインでき、常に正常に展開できます。次に、修正プログラムからパッチを作成し、開発ブランチに適用します。

もちろん、このワークフローは、SVNではないものにはるかに適しています。これは、ワークフローに関係なく、SVNでは適切な分岐とマージが非常に苦痛なものだからです。私の経験では、SVNでのマージはほとんどの場合手動で実行する必要があります。SVNは機能しないだけで、実際に回避する方法はないためです。

最近、私は最後の結果として「ブランチとマージ」の哲学を提唱しています。ブランチからのコードのマージを処理することは技術的な問題ではないことは残念なことですが、それは認識的に困難なタスクです：人間の脳が簡単にするのに十分な詳細を追跡していないだけだと思います。さらに、実際にブランチとマージが実際に機能することをまだ確認していません。コードが分岐すると、経験から、再度マージするのは面倒なことではないことがわかります。

統制のとれたリリースオンメインのアプローチがうまく機能します。

SVNの分岐は柔軟に設計されていません。最初の問題はSVNにあることをお勧めします。それから移動すると、新しいオプションが開かれます。