如何避免大型组织的分支机构化？

与大型组织合作时，如何避免出现分支机构化情况？

我们与许多大型金融机构合作，其方法是不对软件进行更新，而仅对高/关键安全补丁和定制功能进行更新。这些组织仅在主要更新之间进行补丁和自定义发行。重大更新可能相隔数年，并且成本高昂。这种方法使我们（软件公司）对每个主要客户都有自己的代码分支，这负担了长期分支的所有成本和效率低下。

我对社区的问题是：

• 您是否经历过客户的类似更新接受方法？
• 您有什么建议可以帮助您使用此方法？
• 您需要什么建议来帮助改变组织进行软件更新的方法？

如Michael所述，提供基于发行版本/编号的标准解决方案，并为您的行业提供相当长的使用寿命（如果对您的典型客户有意义，则可以与一个或多个较短使用寿命的中间版本交错使用）。

给您的客户选择进入此标准发布轨道的选择，也许有适当的迁移截止日期。

如果他们坚持采用完全自定义的分支机构支持策略，只需向他们收取相应费用，以适当支付您提供此类完全自定义支持的所有额外费用-这仅具有商业意义。一些客户将迁移以降低成本（这将帮助您减少自定义分支的数量），而有些则不会。

可变支持计费随着定制分支机构所源自的发行版本的使用而逐渐增加，这也可以激励客户更快地迁移到较新的分支机构，从而有助于更快地关闭较早的定制分支机构。如果您有同时运行多个软件版本的客户，这可以帮助减少每个客户的自定义分支数量。

确保不陷入对任何发行分支（包括标准分支和定制分支）进行完全分支合并的陷阱，对它们的所有更改都应单独开发或选择精心挑选的合并修订。

由于这些分支中的每个分支都将逐渐彼此分离，因此需要自定义/个性化开发的修补程序数量将成倍增长（普通的pick-pick合并将失败）。您需要考虑这些的开发成本。

图片中没有（重要的）分支合并，您可以（并且我应该强调的重要性不大）为这些分支构建全自动的CI / CD管道，并配备适当的修补程序跟踪/管理系统，以进行修补程序交付只是常规（或几乎）。

也许如果您按版本而不是按客户维护分支机构，可能有助于减少分支机构的数量？

否则，真正摆脱它的唯一方法是能够自己托管该软件并切换到SaaS模型，在该模型中您将只能维护该软件的一个版本。