各スプリントの複数のブランチ/開発者からのコードの統合をどのように処理しますか？
各スプリントごとにマスターブランチにストーリーを統合することについて開発者が懸念を表明するというレトロな電話を切ったところです。開発者はすべて自分のブランチ内のコードをすべて、スプリントの終わり頃にすべて1つのマスターブランチにマージします。
次に、1人の開発者（通常は同じ開発者）は、すべてが他の開発者のコードと適切に統合されていることを確認するタスクを残されます（ほとんどの変更は同じページにあります。たとえば、データ表示ストーリー、データフィルタリングストーリー、 a SLAインジケーター）。
この負担を軽減し、コードを簡単にマージできるようにするにはどうすればよいですか？私の観点からは、POまたはSMがより効率的な方法でストーリーに優先順位を付けることで、同じスプリントにこのような依存関係がなくなるため、いくつかの問題が解決する可能性があります。他の誰もがこれにどのように取り組みますか？それとも、これはプロセスの一部ですか？
Gitを使用している場合、各開発者はdevelopブランチから独自のfeatureブランチにプルし、現在のベースラインから遠すぎないようにします。彼らは毎日それを行うことができるので、2日以上かかるタスクは同期を保ち、マージの問題は小さいまま解決されます。
開発者が作業を完了すると、pull requestが作成されます。承認されると、developブランチにマージされます。
developブランチには常に機能するコードがあり、いつでもリリースできる状態になっている必要があります。実際にリリースするときは、developをmasterにマージしてタグを付けます。
良好な継続的統合サーバーがある場合、変更がチェックインされると、特にプルリクエストの場合に、各ブランチが構築されます。一部のビルドサーバーはGitサーバーと統合して、ビルドが失敗した場合、または自動テストが失敗した場合に、プルリクエストを自動承認または不承認にします。これは、潜在的な統合バグを見つける別の方法です。
私は同じ問題に苦しんでいるチームで働いていました。統合するまでの時間が短いほど、難易度が低くなることがわかりました。継続的インテグレーションを教えるほとんどの人は、数分ごとにコミットすることについて話していることを知っています。
また、構築だけでは不十分であることもわかりました。お互いのコードを誤って壊さないようにするために、適切なテストカバレッジレベルが必要でした。
- ブランチの存続期間を短くしてください（既にこれを行っているようです）。
- あなたのテスト結果がそれを物語っています。
- スプリントの終了を待たないでください。
このためにTDDを購読する必要さえありません。必要なのは、開発者の機能が正しく動作していることを証明するいくつかのテストです。これらには、単体テストと統合テストを含めることができますが、理想的には重要な機能の自動化されたエンドツーエンドのテストのカップルになります。標準回帰パックのもの。
次に、マージが完了したら、自動化テストレポートを一緒にチェックして、すべてが正常に統合されたことを確認できます。
著者がGit PRが各開発者に自分の作業をマージしてこの問題を解決すると述べた他の回答の1つに同意します。
私が信じているもう1つの点は、最後の段落まで残すために十分に重要です。スプリントの終了を待たずに、毎晩のビルドで手動テストを実行することをお勧めします。 開発者は、機能が完成したらすぐに統合して、できるだけ早く統合、展開、テストできるようにする必要があります。
しないでください
言語や編集しているファイルによっては、各開発者が独自のブランチで編集することは意味がない場合があります。たとえば、C＃では、UIデザイナファイルを一度に編集するのは1人だけが最善であることがわかりました。これらは自動生成されたファイルであるため、明らかな理由なしにコードが移動されることがあります。これは、ほとんどのマージツールに大混乱をもたらします。
つまり、UIの作業が完了するまで、一部のストーリーが他のストーリーをブロックする可能性があります。または、UIをレイアウトするためだけに新しいストーリーが作成され、他のストーリーが機能を実装します。または、1人の開発者がすべてのUI作業を行い、他の開発者がそのUIの機能を実装する場合もあります。
関連するメモとして、複数のストーリーがすべて同じファイルにアクセスすることがわかっている場合は、それらすべてを同時に処理することを避けたい場合があります。それらをすべて同じスプリントに入れたり、1つ以上が完了するまでそれらすべてに取り組み始めたりしないでください。
機能フラグ：遅くて大規模なマージを回避するための別の可能なアプローチは、（理想的には動的に）構成可能なフラグで変更を保護し、以前にアクティブになるのを防ぎます意図されました。
これにより、何も壊すことなく、変更を早期にmasterまたは共同開発ブランチにマージできます。他の開発者は、これらの変更を機能ブランチにマージして戻す（またはそれに応じてブランチをリベースする）ことができます。
他の回答がすでに指摘しているように、これは継続的インテグレーションソリューションと組み合わせる必要があります。
機能フラグには追加の利点があります（たとえば、A/Bテストを簡単に行うことができます）。詳細は この記事はMartin Fowlerによる を参照してください。
機能ごとに個別の開発ブランチのアプローチに従い、統合テスト環境でテストするために、ブランチをQAブランチにマージします。
回帰テストと統合テストが完了すると、すぐに使用できる機能をリリースブランチに簡単に移動できます。
すべてがうまくいけば、リリースブランチをマージしてマスターブランチに戻します。
簡単に言えば、コミットとマージを行うと、マージ競合の機会が減り、競合が大幅に減少します。もう1つは確かにリードによる計画です。これにより、作業をスムーズに進めることができます。
他の回答は、コミットのベストプラクティスに関する優れた洞察を提供します。コミットメントのベストプラクティスに従うだけで、マージの問題の大部分を減らすことができます。マージの増加はほぼ確実に必要ですが、小規模なチームの場合、1人あたりのブランチのアプローチはおそらく十分に機能します。もちろん、より拡張可能なプラクティスに入るのは（大いに）害にはなりません！
ただし、最も重要な質問の1つ、つまり、コードの同じ領域に全員が触れているときに何をすべきかについて、誰も対処していないようです。これは、コードベースに精通していて、さまざまなタスクの依存関係を認識できるリーダーがいると便利です。作業とコミットのタイミングを調整しないと、マージの競合と行ごとの解決が発生する可能性があります。大規模なチームでは、タスクのタイミングを調整することははるかに困難ですが、小規模なチームでは、これらの競合するタスクを特定することが可能です。リーダーは、すべての関連タスクを同じエンジニアにシフトして、競合を完全に回避することもできます。