私の会社は支店の合併は間違っていますか？

最近、分岐とマージとSCMについてのMSDNの記事に出くわしました：分岐とマージプライマー-Chris Birmele。

記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。

Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。

これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。

私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク（subversion）から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。

トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。

10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。

また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します（poor mans rebase）。

私が持っているいくつかの直接的な質問は次のとおりです。

• 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？
• このマージプロセスの結果に見られる問題の一部はありますか？
• 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？

編集：私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。

この状況に関する他の洞察は歓迎されます。

いくつかの提案：

• 各ブランチで行われた変更が十分に小さく、結果として生じるマージの競合を効果的な方法で処理できる限り、多くの機能ブランチまたはバグ修正ブランチを作成しても問題はありません。これは、MSDNの記事ではなく、作業方法に問題がない場合の基準です。

• ブランチがトランクにマージされるたびに、トランクはすべてのオープン開発ブランチにできるだけ早くマージされる必要があります。これにより、チーム内のすべてのユーザーが自分のブランチでマージの競合を並行して解決できるため、トランクのゲートキーパーからある程度の負担がかかります。

• ゲートキーパーが10個のブランチが「トランクへのマージの準備ができる」まで待機しない場合、これはより適切に機能します。最後のトランク統合からのマージ競合の解決には、チームに常にある程度の時間が必要です。 -ゲートキーパーによる1つの統合、チームによる1つの再マージ、ゲートキーパーによる次の統合、チームによる次の再マージなど。

• ブランチを小さく保つには、大きな機能をいくつかの小さなタスクに分割し、それぞれのタスクを独自のブランチで開発すると役立つ場合があります。すべてのサブタスクが実装されるまで機能の生産準備が整っていない場合は、すべてのサブタスクが完了するまで、機能切り替えの背後で生産から非表示にします。

• 遅かれ早かれ、コードベースの多くのファイルに影響を与えるリファクタリングタスクに遭遇します-これらは多くのブランチとの多くのマージ競合を引き起こす高いリスクを持っています。それらをチームで明確に伝え、上で書いたようにそれらを正確に処理することによってそれらを最適に処理できます：再統合の前にすべてのdevブランチにそれらを最初に統合し、それらをより小さなサブリファクタリングに分割します。

• 現在のチームサイズでは、単一のゲートキーパーがまだ機能する場合があります。ただし、チームの規模が大きくなると、2番目（またはそれ以上）のゲートキーパーを確保する方法がなくなります。注：全員がトランクにマージできるようにすることを提案しているわけではありませんが、それはあなたの上司だけがこれを実行できるという意味ではありません。おそらく、ゲートキーパーの仕事をするための候補者になる可能性のある1〜2人の上級開発者もいます。また、現在のチームの規模であっても、2番目のゲートキーパーを使用すると、チームをより頻繁に、より早く、または上司がいないときにトランクに統合しやすくなります。

「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？

それのように聞こえます。

このマージプロセスの結果に見られる問題の一部はありますか？

間違いなく

上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？

私の会社では、すべての開発者がマージする能力を持っています。マージリクエストを別の開発者に割り当て、双方が満足するまでレビュー/フィードバック/更新サイクルを実行します。次に、レビュー担当者がコードをマージします。

マージされるのを待っている10〜20のブランチは、プロセスに欠陥があることを示しています。多数ある場合、すべての開発作業は、解決されるまで停止します。

これは基本的に、多くのオープンソースプロジェクトが機能する方法です。最も顕著なものは、Linuxカーネルです。これらのプロジェクトでビッグバンマージを回避する一般的な方法は、継続的な統合のために別のブランチ（または複数のブランチ）を作成することです。これは、変更を同僚と確実に連携させるために使用するブランチであり、ゲートキーパーがレビューを実行するときに定期的にトランクにリベースされます。

必要に応じて、このブランチを使用して、独自のプルリクエストのいくつかを結合して、上司が確認できる1つの大きなまとまりのあるリクエストにすることができます。Linus Torvaldsは通常、2つ以上のレベルに統合されたプルリクエストを取得し、たとえば、完全に新しいファイルシステムドライバーのオーダーのサイズを持つことができます。

私はDoc Brownの両方に同意しますが、別のアンチパターンも見ます：

トランクリポジトリの唯一の権限である上司は、ブランチのレビューすべてを実際に可能な限りレビューする単一の時点まで延期し、一部のブランチは拡張/修正のためにスローされますブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。

私の謙虚さにいくつかの管理アンチパターンがあります：

1. 彼/彼女は、チームの速度を制限する単一のチョークポイントです。あなたのバス係数は1です。制約の理論は、チェーンの最も遅い部分の改善に努力を払うべきだと言っています。
2. マネージャーはフィードバックサイクルを遅くし、チームの俊敏性を低下させています。毎週リリースできますか？
3. マージの複雑さは、コードの量とともに指数関数的に増大します。1000行のうち1行よりも100行で10回マージする方が適切です。それはあなたがそれをできるだけ早く行うべき理由の1つにすぎません
4. トランクで障害が検出された場合は、後ほどそれを実行します。いくつかのブランチのどれが問題のあるブランチでしたか
5. 決断は、彼らについてもっと知識を持っている人によって行われるべきです。この場合の詳細は誰ですか？コードを作成した開発者は間違いないでしょう。
6. マネージャーが休日にいる場合、本番環境のバグを修正することはできません。
7. あなたは仕事をやり直し、枝を投げ返しています。これは時間の無駄です。生産に到達するのを待っている時間も無駄です。

推奨事項：

• マネージャーは、責任をチームに委任する必要があります。チームが成熟し、プロフェッショナルであることを示す必要があります。チームで信頼できることを明確にする
• レビュー方法を実装します。他の2人のチームメンバーの承認が必要な場合があります。
• SVNを使用しているために困難になっている可能性があります。Gitを試してみて、それが役立つかどうかを確認してください。さらに。GitHubを使用する場合は、プルリクエストメカニズムを使用して、マージに特定の投票が必要になるようにすることができます。
• アジャイルプラクティス、継続的インテグレーション、DevOpsに関する情報を読んで共有します。

別々のブランチで機能作業を行う場合、ブランチの1つがトランクにマージされ、他の機能ブランチにプルされるまで、統合テストを簡単に行うことはできません。私の経験では、これがBig Bang Mergeアンチパターンの主な問題です。理想的には、機能の作業を行い、機能ブランチでそれをテストし、トランクにマージして、その時点で機能を完了します。マージされていない場合は、その前に何か他のものがトランクにマージされるたびに再検討する必要があります。このアンチパターンの苦痛は、開発サイクルの終わりに多くの統合タイプのバグが現れることです。

したがって、20のブランチがあります。ブランチ1がマージされました。次に、ブランチ2の開発者は、ブランチ1をブランチにマージして、競合せずにメインにマージしてからマージする必要があります。次に、ブランチ3の開発者は、ブランチ1とブランチ2をそれぞれのブランチにマージして、競合せずにメインにマージしてからマージする必要があります。

読者のための練習：私の完全な投稿を印刷するプログラムを書いてください:-)

これは狂気です。マージに膨大な時間を費やすことになります。

あなたが働いている方法と、あなたの上司が責任あるコントロールマニアであることを考えると、分岐自体が問題のようです。すべての機能にブランチを作成するのではなく、各開発者に自分の機能を直接トランクにコミットさせます。これにより、複数の小さなステップ（win-win）で開発者に統合の負担がかかります。ゲートキーパーは、開発サイクルの早い段階でより小さな期間で小さな変更を追跡し、引き続きマスターレビューアを務めることができます。

分岐自体は、非常に正当な理由がない限り、または他に選択肢がない場合を除き、実行したくないことです。あなたは物事をより緊密に同期させるのに十分小さいため、より簡単で安全になります。