branch - 分岐地獄、リスクと生産性の転換点はどこにあるのでしょうか?

Question

私の会社は、顧客固有の修正を可能にするために、バージョン番号をもう 1 段階 (たとえば、major.minor.servicepack から major.minor.servicepack.customerfix に) 拡張するという考えを浮かび上がらせています。

私の経験では、製品の分岐が増えるほど (そして、顧客の修正はコード ベースの分岐であると私は信じています)、オーバーヘッドが増え、労力が希薄になり、最終的には開発の生産性が低下するため、これは表面的には悪い考えのように思えます。グループになります。

リスク対生産性の議論をたくさん見てきましたが、「これは悪い考えだと思います」と言うだけでは十分ではありません。リスクを回避しすぎて、重い、顧客固有の、ソース コードの分岐、開発モデルを採用することの実際のコストについて、どのような文献がありますか?

少し明確にします。このモデルは、顧客が自分のプライベート ブランチにどのバグ修正を適用するかを制御できることを意味すると思います。一般的なトランクにアップグレードすることはめったにないと思います（このモデルには存在しないかもしれません）。つまり、自分の私的な現実のバブルをコントロールできるとしたら、なぜそうするのですか?

Answer 1

文献では役に立ちませんが、顧客固有の分岐は悪い考えです。そこに行って、それをしました。もちろん、エラーを再現するためにすべての顧客固有のバージョンを利用できるようにする必要があったため、もののデバッグはまったくの地獄でした...しばらくして、コードベースが完全に変わったため、会社はアプリケーションを完全に書き直さなければなりませんでしたメンテナンス不能。(すべての顧客が同じコード行にあるように、顧客固有の部分を構成ファイルに移動します。)

そこに行かないでください。

Answer 2

一般的に、顧客の修正を処理するためのオーバーヘッドが高いことに同意しますが、そうしないとは言いません。

彼らがそれほど多くの注意を必要とするならば、私は顧客に腕と脚（そして彼らのいくつか）を請求すると言うでしょう。それ以外の場合は、顧客の支店を行わないでください。

Answer 3

私の旅行では、良い習慣のほとんどについて明確な文献を個人的に見たことがありませんが、そこにはたくさんのものがあると思います。

バージョン番号は、特定のコード変更セットを使用して、実際の特定のバージョンを結び付けるための非常に単純なメカニズムを提供します。技術的には、バージョン番号にいくつのレベルがあるかは問題ではありません。開発者が、リリースされるすべての「一意の」バージョンに対して「一意の」バージョン番号があることを保証することに熱心に取り組んでいる限りです。

ロジックは、サポートコスト（莫大で、多くの場合、開発コストよりも悪い）を制限するために、合理的な組織は、フィールドで実行される「一意の」バージョンの数を最小限にすることを好むと指示しています。1つは素晴らしいでしょうが、現実の世界には通常かなりの数があります。これは、コストと利便性の問題です。

通常、最初の数字は、この一連のリリースに下位互換性がないことを示しています。次の数字はほとんどがそうであることを示していますが、いくつかの変更があり、最後の数字はいくつかの修正が行われたことを示していますが、ドキュメントはすべて当てはまります。このように使用すると、顧客のサブセットの要求に応じて特定の修正を行った場合でも、4番目の番号は必要ありません。よりクライアント主導になるという選択は、番号付けスキームに影響を与えるべきではありません（したがって、それは悪い考えです）。

顧客の要求に基づいて分岐することは絶対的な狂気です。1つのメイントランクが不可欠であるため、分岐するたびに莫大な技術的負債が発生します。十分に分岐し、あなたはもう興味を払う余裕がありません。

Answer 4

顧客ブランチに入る変更を「修正」と説明します。これらは修正であるため、トランクでも作成されると想定しており、実際には将来のバグ修正の高度な配信にすぎません。この場合、新しい「サービスパック」(質問: major.minor.servicepack から) を作成し、そのバージョンを顧客に提供してみませんか。

1. たとえば、バージョン 1.2.3 をリリースするとします。
2. 顧客 #1 は修正を必要としており、バージョン 1.2.4 を作成して顧客 #1 に渡します。
3. 顧客 #2 は修正を必要としており、バージョン 1.2.5 をクレートし、それを顧客 #2 に渡し、暫定修正も「無料で」入手できることを宣伝します。

Answer 5

文献についてはわかりませんが... 顧客固有の修正をサポートする可能性さえある場合は、少なくとも分岐とバージョン管理の戦略を講じることが賢明です。私は戦略が決して使用されないことを望んでいますが.

危険なのは、修正が必要になった真の問題に対処するのではなく、顧客固有の修正が受け入れられ、標準になるという文化になってしまうことだと思います。

実際のコストは、次のリリースまでに顧客を満足させるための暫定的なバグ修正に過ぎないのか、それとも 1 回限りのカスタマイズなのかによって大きく左右されると思います。前者だけで、量が多すぎなければ気にならない。しかし、そのカスタマイズなら、私は無知で怖いでしょう。