大規模な組織でBranchageddonを回避するにはどうすればよいですか？

大規模な組織で作業するときに、どのようにしてブランチエイジドンの状況を回避しますか？

私たちは、ソフトウェアの更新ではなく、高/重要なセキュリティパッチとオーダーメイドの機能のみを採用するというアプローチを持つ多くの大規模な金融機関と協力しています。これらの組織は、メジャーアップデートの合間にのみパッチとカスタムリリースを取得します。メジャーアップデートは数年離れている可能性があり、コストが高くつきます。このアプローチにより、私たち（ソフトウェアハウス）は、主要な顧客ごとにコードのブランチを作成します。これには、長期ブランチのすべてのコストと非効率性が伴います。

コミュニティへの私の質問は次のとおりです。

• 顧客から同様のアップデート承認アプローチを経験しましたか？
• このアプローチでの作業を支援するためにどのような提案がありますか？
• ソフトウェアの更新を行うための組織のアプローチを変えるためにどのような提案がありますか？

Michaelが述べたように、リリースバージョン/番号に基づいた標準ソリューションを提供します。業界の寿命はかなり長くなります（通常の顧客にとって意味がある場合は、1つ以上の短い寿命の中間バージョンと交互に配置されます）。

この標準リリーストラックに着手するオプションを顧客に提供します。適切な移行期限が設定されている可能性があります。

フルカスタムのブランチサポート戦略を主張する場合は、それに応じて課金するだけで、そのようなフルカスタムサポートを提供するためのすべての追加コストを適切にカバーできます-それはビジネスに意味があります。一部のお客様は、コストを削減するために移行します（カスタムブランチの数を減らすのに役立ちます）。

可変サポートの請求は、カスタムブランチの元のリリースバージョンの経過に伴って次第に大きくなり、新しいカスタムブランチにすばやく移行するためのインセンティブとなり、古いカスタムブランチをすばやく閉じるのに役立ちます。これにより、ソフトウェアの複数のバージョンを同時に実行する顧客がいる場合、顧客ごとのカスタムブランチの数を減らすことができます。

すべてのリリースブランチ（標準およびカスタムの両方）との間で完全なブランチマージを行うという罠に陥らないようにしてください。それらに対するすべての変更は、個別に開発するか、厳選したマージされた修正でなければなりません。

これらの各ブランチは徐々に互いに分岐するため、カスタマイズ/個別開発を必要とする修正プログラムの数は指数関数的に増加します（単純なチェリーピックのマージは失敗します）。これらの開発コストを考慮に入れる必要があります。

画像に（重要な）ブランチマージがない場合、これらのブランチ用の完全に自動化されたCI / CDパイプラインを構築し、適切なホットフィックス追跡/管理システムを配置して、ホットフィックスの配信を行うことができます。ちょうどルーチン（またはほぼ）。

おそらく、顧客ごとではなくバージョンごとにブランチを維持している場合、その数を減らすのに役立つでしょうか？

それ以外の場合、実際にそれを回避する唯一の方法は、ソフトウェアを自分でホストし、SaaSモデルに切り替えて、そのバージョンの1つだけを維持できるようにすることです。