我们与许多大型金融组织合作，其方法是不对软件进行更新，而仅对高/关键安全补丁和定制功能进行更新。这些组织仅在主要更新之间进行补丁和自定义发行。重大更新可能相隔数年，并且成本高昂。这种方法使我们（软件公司）对每个主要客户都有自己的代码分支，这承担了长期分支的所有成本和效率低下。
我对社区的问题是：
您是否经历过
客户类似的更新接受方法？
您需要什么建议来帮助您使用此方法？
您需要什么建议来帮助组织变革
进行软件更新的方法？
#1 楼
正如Michael提到的，请提供基于发行版本/编号的标准解决方案，并为您的行业提供相当长的使用寿命（如果对您的典型客户有意义，则可以与一个或多个较短使用寿命的中间版本交错使用）。为您的客户提供选择此标准版本的途径，也许有适当的迁移截止日期。
如果他们坚持采用完全定制的分支机构支持策略，只需向他们收取费用即可，适当地支付您提供这种完全定制支持的所有额外费用-这仅具有商业意义。一些客户将迁移以降低成本（这将帮助您减少自定义分支的数量），而有些则不会。
随着自定义分支机构发行版本的发布，版本的支持费用不断增加，这也刺激了客户更快地迁移到新的分支机构，从而更快地关闭了旧的自定义分支机构。如果您有同时运行多个软件版本的客户，这可以帮助减少每个客户的自定义分支数量。
请确保您不会陷入从/进行完全分支合并的陷阱对于任何发行分支（标准发行版和自定义发行版），对它们的所有更改都应单独开发或选择合并式修复。
因为每个分支将逐渐彼此分离，所以需要自定义/个性化开发的修补程序数量将成倍增长（纯樱桃挑选式合并将失败）。您需要考虑这些的开发成本。
图片中没有（重要的）分支合并，您可以（并且我应该强调的重要性不大）可以构建全自动的CI / CD管道对于这些分支机构，并配有适当的修补程序跟踪/管理系统，使得修补程序的交付只是例行的（或几乎是常规的）。
评论
丹-很明显而且很简单，但是很有意义。金钱使世界运转，反过来应该帮助我们补偿长期存在的分支机构的成本，或者鼓励客户升级并保持靠近主干。谢谢您的好建议。
–马克·惠勒
18年2月22日在16:07
#2 楼
也许如果您按版本而不是按客户维护分支机构，这可能有助于减少分支机构的数量？否则，真正摆脱它的唯一方法就是能够自己托管软件并切换到SaaS只能维护一个版本的模型。
评论
不幸的是，由于客户使用的财务数据，我们的客户通常在非常停机的环境中工作，因此SaaS模型是不可接受的。
–马克·惠勒
18年2月22日在16:05
评论
嗨，马克，听起来您有一个有趣的难题。您如何管理每个客户更新的开发？您是为每个客户一次性开发它们，还是将其开发并应用于所有客户？就个人而言，在这种情况下我可能会寻找其他工作。这听起来像是一个安全事件正在等待发生……我可以告诉您我所服务的设备供应商，他们有一个主要错误，该错误已在据报道无法解决的更新中修复。他们想要自定义修复程序。我们拒绝构建它们，并告诉他们他们需要修正其业务策略-我们不会针对已经修复的错误发布自定义修补程序，只是为了避免内部政治问题。
我们通过多个代码分支管理自定义客户端特定的更新，并交叉修复所有分支的安全性更新，然后将分支代码交叉修复回主干。客户A通常不会在其分支机构中获取客户B的更新，而只会获取自己的更新和安全补丁。这是出于对他们分支机构稳定性的渴望，因此他们只需要测试与他们相关的更新即可。当他们准备好运行完整的测试重新运行时，他们进行中继更新的频率会降低（即数月至数年），而完成更新可能要花费数月的时间。自动化测试可能是答案！