各スプリントの複数のブランチ/開発者からのコードの統合をどのように処理しますか？

開発者は、各スプリントのマスターブランチへのストーリーの統合について懸念を表明するレトロコールを終了しました。開発者はすべて自分のブランチ内のコードを作成し、スプリントの終わりに向かってすべて1つのマスターブランチにマージします。

次に、ある開発者（通常は同じ開発者）に、すべてが他の開発者のコ​​ードとうまく統合されていることを確認するタスクを残します（ほとんどの変更は同じページにあります。たとえば、データ表示ストーリー、データフィルターストーリー、 SLAインジケータ）。

この負担を軽減し、コードをより簡単にマージするにはどうすればよいですか？私の観点からすると、POまたはSMがストーリーをより効率的な方法で優先順位付けすることで、同じスプリントでこれらの種類の依存関係がなくなるため、いくつかの問題が解決する可能性があります。他のみんなはどのようにこれに取り組んでいますか？または、これはプロセスの一部ですか？

Gitを使用している場合、各開発者はdevelopブランチから独自の機能ブランチにプルして、現在のベースラインからあまり遠くに行かないようにします。彼らは毎日それを行うことができるので、数日以上かかるタスクは同期されたままで、マージの問題はまだ小さいうちに解決されます。

開発者が作業を完了すると、プルリクエストを作成します。承認されると、developブランチにマージされます。

developブランチは、常にコードを働いていて、いつでもリリースの準備ができているはずです。実際にリリースするときは、マージdevelopしmasterてタグを付けます。

適切な継続的インテグレーションサーバーがある場合、特にプルリクエストの場合、変更がチェックインされると各ブランチが構築されます。一部のビルドサーバーはGitサーバーと統合して、ビルドが失敗した場合や自動化されたテストが失敗した場合に、プルリクエストを自動承認または不承認にします。これは、潜在的な統合バグを見つける別の方法です。

私は同じ問題に苦労したチームで働いていました。統合するまでの時間が短ければ短いほど、難しくはならないことがわかりました。継続的インテグレーションを教えるほとんどの人が、数分ごとにコミットすることについて話していることを知っています-私たちはおそらく実際に1時間ごとにコミットしました。

また、建物だけでは不十分であることがわかりました。誤って互いのコードを壊さないようにするために、適切なテストカバレッジレベルが必要でした。

• ブランチを短命にしてください（すでにこれを行っているようです）。
• テスト結果がわかるようにします。
• スプリントの終了を待たないでください。

このためにTDDをサブスクライブする必要さえありません。必要なのは、開発者の機能が正しく機能していることを証明するテストだけです。これらには、単体テストと統合テストが含まれる可能性がありますが、理想的には重要な機能の自動化されたエンドツーエンドのテストのカップルになります。標準の回帰パックのもの。

次に、マージが完了したら、自動化テストレポートを一緒にチェックし、すべてが正常に統合されたことを確認できます。

著者は、Git PRが各開発者に自分の作業をマージさせることでこの問題を解決すると述べた他の回答の1つに同意します。

私が信じているもう1つのポイントは、最後の段落まで残すのに十分重要です。スプリントの終了まで待つのではなく、夜間のビルドで手動テストを実行することをお勧めします。開発者は、機能が完成したらすぐに統合して、できるだけ早く統合、展開、およびテストできるようにする必要があります。

しないでください

言語と編集しているファイルによっては、各開発者が自分のブランチで編集することは意味をなさない場合があります。たとえば、C＃では、一度に1人のUIデザイナーファイルのみを編集するのが最適であることがわかりました。これらは自動生成されたファイルであるため、明確な理由なしにコードが移動される場合があります。これにより、ほとんどのマージツールが大混乱に陥ります。

これは、UIの作業が完了するまで、一部のストーリーが他のストーリーをブロックする可能性があることを意味します。および/または、UIをレイアウトするだけの新しいストーリーが作成され、他のストーリーが機能を実装します。または、1人の開発者がすべてのUIの作業を行い、他の開発者がそのUIの機能を実装する場合があります。

関連する注意事項として、複数のストーリーがすべて同じファイルに触れていることがわかっている場合は、それらのストーリーをすべて同時に処理しないようにすることができます。すべてを同じスプリントに引っ張ったり、1つ以上の作業が完了するまで作業を開始したりしないでください。

遅延および大規模なマージを回避するための別の可能なアプローチは機能フラグです。変更を意図した前にアクティブにならないようにする（理想的には動的に）設定可能なフラグで変更を保護します。

これにより、master何も壊すことなく、変更を早期に、または共同開発ブランチにマージできます。他の開発者は、これらの変更を機能ブランチにマージして戻す（またはそれに応じてブランチをリベースする）ことができます。

他の答えがすでに指摘しているように、これは継続的な統合ソリューションと組み合わせる必要があります。

機能フラグには追加の利点があります（たとえば、A / Bテストが簡単になります）。詳細については、Martin Fowlerによるこの記事を参照してください。

機能ごとに個別の開発ブランチのアプローチを採用しており、統合テスト環境でテストするためにブランチをQAブランチにマージしています。

回帰テストと統合テストが完了すると、すぐに使用できる機能をリリースブランチに簡単に移行できます。

すべてがうまくいけば、リリースブランチをマスターブランチにマージします。

簡単に言えば、コミットとマージはマージ競合の機会を減らすことが多く、競合を大幅に減らします。他の部分は、実際にリードが計画を立てているため、作業がスムーズに流れるようになります。

他の回答は、コミットのベストプラクティスに関する優れた洞察を提供し、単純にそれらに従うことで、おそらくマージの問題の大部分を減らすことができます。マージを増やすことはほぼ確実に必要ですが、小規模なチームの場合、1人あたりのブランチアプローチはおそらく十分に機能します。もちろん、より拡張性の高いプラクティスを開始しても、それほど痛いことはありません！

ただし、最も重要な質問の1つ、つまりコードの同じ領域に全員が触れている場合の対処方法について、誰も対処していないようです。これは、コードベースに精通しており、さまざまなタスクの依存関係を認識できるリードがいると便利です。作業とコミットのタイミングを調整しないと、マージの競合と行ごとの解決に終わる可能性があります。大規模なチームではタスク\タイミングを整理することははるかに困難ですが、小規模なチームではこれらの競合するタスクを特定することが可能です。リードは、競合を完全に回避するために、関連するすべてのタスクを同じエンジニアにシフトすることさえできます。