手机银行中的单分支开发或主干开发

长期维护的特性分支,这种做法会为每个新的大型特性或项目建立一个分支,仅当准备发布时才合并回到主干上。看似可以独立地开发每个特性,互不干扰。不幸的是,软件系统是如此复杂,随着主干与分支渐行渐远,接下的合并工作本身将会成为一个项目,带来无数的新缺陷,这真是一场噩梦。
当团队需要同时支持多个客户的不同需求时,版本控制仓库中很可能为此存在了许多分支。这显然会造成大量重复浪费以及高昂的维护成本,在临近产品发布时带来巨大风险。

2011年,@申导 进入某银行的网上银行工作。由于各国市场环境、政策法规等原因,以借记卡为例,看似相同的业务和账户,其背后的处理逻辑和外部集成系统可能都是不一样的。
当时的代码库中,多个国家的代码互相拷贝,由不同组维护,各有自己的思路,虽然最早是同一个基础框架发展而来,但短短几年后各自结构和规范差别越来越大。比如,页面login有的在iframe里,有的不在。相同的修改需要到处merge,例如安全性补丁,回归测试工作量大。

秋天,他所领导的敏捷团队开始开发新一代手机银行项目,目标是用同一代码库来支持多个国家的业务需求。

2011秋开始立项,某一个国家的项目率先开始。团队没有一下子设计一个完美的方案,因为当其他国家的需求不明时,根本也不可能有一个完美的方案。只是确定下了基本数据结构和MVC的层次,还有技术栈和构建方案,称之为“可行走的骨架”,随时根据变化来调整架构设计和构建方案,满足对不同国家需求的支持。
首先选定的技术栈是用Maven来管理web工程,采用Jasmine和RobotFramework分别作为单元测试与自动化测试工具。这几个工具都是非常流行,而且易于与Jenkins系统结合,构建持续集成系统。

在这种跨国多团队合作的场景下,好几个国家的项目同时由不同的团队开展,而且打破界限,大家都在SVN主干上进行开发,如果 没有持续集成系统作为反馈和沟通的基础,简直是无法想象的。利用CI,可以快速发现提交测试不完整带来的问题,暴露各人开发环境差异带来的影响,以便尽快修复,避免破窗效应。

在架构的演进过程中,团队充分利用语言和框架的各种多态特性,适时将不同的变种与公共部分剥离出来,将公共代码抽象为”基类”置于单独的软件包中。逐渐地,公共代码演化为“平台”代码,提供公共功能,而每个国家不同的业务逻辑则拼接于”平台”之上。这种通过不断抽象来管理不同分支的方式,称为“以抽象为分支”。(http://martinfowler.com/bliki/BranchByAbstraction.html)

除了代码,单元测试与自动化测试同样也采用单分支策略。

单分支开发(主干开发)的关键注意事项:

  • ”特性开关Feature Toogle“或“以抽象为分支Branch By Abstraction”的架构技术来隔离掉未完成的特性。特性开关是系统中简单的配置开关,使得特性被关闭。以抽象为分支通过在软件内创建新的抽象层,来避免创建新的分支,新老特性得以共存。两种技术都是主干开发的必要条件,以循序渐进的方式进行大规模的软件变化,使你能够在变化进行中仍然可以有节奏地发布软件,同时保证大型特性在有效地完成之前不会被用户使用。
  • 将大型特性分解成细粒度的特性,从而可以增量地发布。这也有助于提高发布管理的可预测性和计划的灵活性。
  • 当测试周期很长时,建议采用”发布分支Release Branch“,在发布到生产环境之前进行版本冻结,仅修复缺陷而不增加任何新特性,从而稳定质量水平。这与传统的SCM策略截然相反。

    更多细节,见:

  • 苏州开发者大会2013话题 http://softwaresuzhou.org/topic-single-branch-development/

  • Scrum Gathering 2013候选话题 http://vdisk.weibo.com/s/waw152TRJrC
  • 天津软件沙龙 2013话题 http://vdisk.weibo.com/s/waw152TRJrC

觉得本文有帮助,长按二维码进行微信打赏