银行持续交付实战:一个单体系统足以撑起全球大项目

标签: 银行 持续交付 单体 | 发表时间:2020-05-10 10:06 | 作者:dbaplus社群
出处:https://www.infoq.cn

本文由 dbaplus 社群授权转载。

我们的核心系统是一个单体系统,支撑全球多个国家和地区的业务。同时,业务部门近年生意红火,接了几个大客户,针对这些大客户的大型项目也在如火如荼地进行中。

由于生产环境只有一套,而且已经有业务在生产环境上跑,这些大项目最终也要在这套生产环境上上线。这套系统是糅合了各地、各不同业务的复杂系统。

之前,为了满足各个客户交付时间,每个项目都拉了一个独立的分支进行开发,减少各项目之间的依赖,但这也导致了每个项目各自为政,互不交流。一旦这些项目开发完成,要和生产环境的版本进行合并。这种巨型合并势必带来巨大风险,相互隔绝的开发模式也将带来大量的合并冲突。

我们一直在思考如何降低这种合并风险,以及如何打破各大型项目各自为政的困局,实现产品化的敏捷交付。回归测试成为实现这些使命的基础。

使命——实现敏捷交付

前面提到,目前的开发模式是针对不同的大客户,分别设立了不同的大型项目进行开发。这些项目的交付周期往往数以年计,交付周期长,风险大。

生产环境又只有一套,而且已经有业务在生产环境上跑,代码合并困难,上线风险巨大。

我们希望能打破这种大型项目的交付形式,以产品化的思维进行管理。

具体实施的思路是:

  1. 合并——对各大型项目的现有代码与生产环境的版本进行一次性的合并;
  2. 统一Backlog——各类需求(包括现在以大型项目形式服务的大客户的需求)以用户故事的形式进入到同一个Backlog;
  3. Scrum——建立以Scrum为形式的持续交付机制,以一个月作为Sprint的周期,通过Sprint计划会议敲定Sprint的交付计划;
  4. 持续交付——每个Sprint完成计划内各用户故事的交付全流程,包括回归测试和上线到生产环境。

要实现以上模式,上线前的回归测试至关重要。而且由于一个Sprint内,也就是一个月内,要完成Sprint交付计划内所有用户故事的需求澄清、设计、开发、测试、用户验收和上线,时间非常紧,回归测试也必须在一、两天内完成。

如何实现既能充分保护生产环境,又能实现快速反馈的回归测试,成为一个重要议题。

自动化大量功能测试不可行

对于如何设计和实施覆盖率高、执行稳定而且快速的自动化回归测试,一直是一个难题。

我们曾经的一个思路是把现有的功能测试用例进行自动化,但很快发现这个思路不可行,主要原因如下:

  1. 只能依赖UI测试——由于核心系统是供应商产品,开发是由供应商负责的,对我们来说就是个黑盒子,我们只能通过UI进行测试。众所周知,UI的自动化测试,开发、维护成本高,脆弱而且执行时间长;
  2. 无法快速反馈——通过功能进行覆盖,要求不断增加测试用例来提高覆盖率,由于UI测试的执行时间长,用例越多,整体执行时间越长,如果执行周期要数以天计,则无法达到快速反馈的目的;
  3. 性价比低——功能测试用例的覆盖率其实是不可见的,即使把所有功能测试都自动化了,其实际覆盖率依然不高,也就是说这个投入的性价比很低。

我们必须要寻找一种方法,以最小的投入获取最大的保障。

我们对回归测试自动化的预期进行了重新定位。 我们进行回归测试,就是要保护生产环境的关键业务可以照常进行。我们要防止的,是新的特性发布造成生产环境灾难,也就是导致关键业务无法进行的大面积故障。 对于非灾难性的小故障,完全可以通过运维手段来处理。

因此,我们不应该把回归测试定位为防止一切问题。

以不变应万变

基于以上对回归测试预期的重新定位,我们和业务部门协商,请他们列举出当前在生产环境上最关键的业务过程有哪些。我们要保证的是, 当新的特性上线后的首个交易日,原有的最关键的业务过程不会受到严重影响。

基于这个预期,我们以业务部门提供的关键业务过程作为测试用例,并形成以下的回归测试思路:

准备阶段:

  1. 在某个测试环境里,系统版本与生产环境版本相同;
  2. 备份环境数据;
  3. 以某个交易日为基准,执行相应的测试用例;
  4. 备份输入、输出数据(包括生成的接口文件和报表)。

执行阶段:

  1. 在该测试环境里,导入在准备阶段备份的环境数据;
  2. 升级系统到目标版本;
  3. 以准备阶段相同的交易日和相同的输入数据(在准备阶段已备份)执行相同的测试用例,生成相应的接口文件和报表;
  4. 与准备阶段的输出(接口文件和报表)进行比对;
  5. 如果目标版本的输出与原版本的对比没有非预期的差异,视为通过。

简单总结, 就是对比两个系统版本在相同测试环境、相同环境数据、相同交易日、相同输入的情况下,输出是否有非预期的差异。

这个思路的最大特点是,以不变应万变。生产环境的关键业务过程不会经常变化,也就是说测试用例基本上比较固定。通过反复运行固定的测试用例实现回归测试的目标,保护生产环境上的关键业务过程,避免灾难。以最少的用例实现最大的保护。

而且测试的结果验证是通过比对不同版本的输出,我们 不必在乎具体的输出内容 ,只需要关注输出是否有非预期差异。

当然,一旦有新的大客户上线,也就是有新的关键业务过程,这些过程也应该放入到回归测试用例中,当然,用例的选择还是以避免灾难为准则。

在前面提到的功能测试思路里,我们需要不断增加测试用例以增加测试覆盖率,但是由于测试只能在UI进行,这样无限增加功能测试用例是不可持续的。

通过实践,我们发现要充分发挥这个新思路的价值,要注意以下几点:

  1. 专属环境——由于这套环境需要反复整理环境数据和升级,一定要为这个回归测试准备一套专属的测试环境,不要在共享的环境里进行;
  2. 明确检查点——由于执行测试输出的接口文件、报表里一定有时间戳、自增ID等每次执行都会变化的信息,不能简单通过文件来比对。在拟定测试用例时,就应该明确这些接口文件、报表里的有哪些数据需要检查。在每个版本交付时,开发人员也应该明确告知哪些数据检查点会有预期差异。否则对比工作将耗费大量的时间和精力;
  3. 变更范围要小——如果对比的两个系统版本的变更范围太大,会导致输出有大量差异,比对意义不大。因此这个方法不太适合大的合并,比较适合落实了敏捷交付后,由于每个Sprint的变更范围较小,两个系统版本间的输出差异不多,比对较容易。

以这个思路建立了回归测试框架,我们便可以着手执行过程的自动化,从而提升其执行的效率。

总结

我们的核心系统是一套单体复杂系统,支撑全球多个国家和地区不同的业务。

为了实现敏捷交付,我们希望打破目前以大型项目为形式的各自为政,把各项目的所有需求放在统一的Backlog通过Scrum的方法进行持续交付。

要实现这一点,我们需要在每个Sprint都进行有效的回归测试,以保护生产环境的关键业务在新特性上线后不会有灾难性的故障。

通过对比两个系统版本在相同测试环境、相同环境数据、相同交易日、相同输入的情况下,执行关键业务过程的有限的测试用例,输出是否有非预期的差异的回归测试方法,以少胜多,以不变应万变,持续保护生产环境的核心业务,为持续交付保驾护航。

作者介绍

刘华(Kenneth),就职于世界500强银行,负责基金服务业务软件开发与交付,DevOps团队负责人。敏捷、精益、DevOps领域专家,精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈。著有《猎豹行动:硝烟中的敏捷转型之旅》一书。

原文链接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787928&idx=1&sn=610825e3cb730f6294a685e1e102e9f0&chksm=f3f965cdc48eecdb5cffbdf7ffa7c02aba82d4edcf5b43e2eff14e467e10d29111455b511c22&scene=27#wechat_redirect

相关 [银行 持续交付 单体] 推荐:

银行持续交付实战:一个单体系统足以撑起全球大项目

- - InfoQ推荐
本文由 dbaplus 社群授权转载. 我们的核心系统是一个单体系统,支撑全球多个国家和地区的业务. 同时,业务部门近年生意红火,接了几个大客户,针对这些大客户的大型项目也在如火如荼地进行中. 由于生产环境只有一套,而且已经有业务在生产环境上跑,这些大项目最终也要在这套生产环境上上线. 这套系统是糅合了各地、各不同业务的复杂系统.

探路持续交付

- gengmao - 梦想风暴
眼下的这个项目是一个有趣的项目,它让我收获极大的部分并不在于写代码本身,更多的是关于软件开发的“Last Mile”. 自动化,让团队从繁琐重复中解脱出来的一个重要途径,这是所有一切的基础. 在给InfoQ写的一篇文章中,我已经尝试总结了一些通用的内容,这里不再赘述. 之前参与过的一些项目,很大的一个挑战在于环境.

持续交付模式

- - 博客园_知识库
   英文原文: Patterns for Continuous Delivery.   当你有了持续集成需要的构建服务器和脚本之后,下一个问题肯定是:“我们该拿这些构建版本怎么办. ”持续交付,以自动化或半自动化方式,将构建版本从一个环境提送(promote)到更接近实际生产的交付准备环境;这常常是公司在这方面演进的下一步.

持续交付话题的一些讨论和心得

- - CSDN博客研发管理推荐文章
周末参加了在杭州举行的持续交付话题沙龙的讨论,将这次活动中的一些精彩问答和经验警句记录下来供大家参考:. ” 持续交付如何让老板看到价值. “,这是当时讨论的比较激烈的话题,大家形成的基本结论是可以通过衡量周期时间来看持续交付前后的变化,如果使用持续交付前的周期时间是1周,运用了持续交付后周期时间变为3天或者更少了那么就为公司提高了竞争力,就比竞争对手更快的退出新产品、功能了.

年度回顾:百度乔梁谈持续交付与DevOps

- - InfoQ cn
在刚刚结束的 第22期百度技术沙龙中,百度项目管理部乔梁( @乔梁QL)来到沙龙现场,并就持续交付、持续集成和DevOps等话题分享自己的经验,并对国内的发展情况给予了展望. 十年前我也曾自己创业,虽然当时做得还算不错,但慢慢发现自己不是一个能把事业和生活安排得很好的人,于是决定继续回来打工. 对于从事软件开发,估计在座的各位90%以上都与互联网行业有关,我属于不小心闯进了这样的一家互联网公司里面的这种.

持续交付(Continuous Delivery)和持续部署(Continuous Deployment)的区别

- - 外刊IT评论
持续交付并不是指软件每一个改动都要尽快的部署到产品环境中. 它指的是任何的修改都已证明可以在任何时候实施部署. 它在微博上激起了活跃的讨论,周四的时候已经被转发了87次,获得了25个赞. 很显然,这是个很火的话题,很多人对持续交付和持续部署之间的区别很困惑. 有必要用超出微博字数限制的文字来说说这个概念.

云纵持续交付环境管理进化历程 - 旁观者 - 博客园

- -
破天(李进庄)、冬草(宋玥辉) 创作于2018-9-10. 一个公司的运维能力强弱和你线上环境敲命令是有关的,. 你越是喜欢上线敲命令,你的运维能力就越弱,. 越是通过自动化来处理问题,你的运维能力就越强. 持续集成(Continuous Integration, CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.

正确使用银行卡

- - 雨中发呆
请大家看清楚了,是网上银行汇款. 不是银行柜台上汇!柜台上的手续费比网上银行贵的. 但有一个例外,邮政储蓄要收0.5%. 工行:0.9%,最低0.9元/笔,最高45元/笔. 农行:0.4% ,最低1元/笔,最高20元(柜台手续费是0.5%,最高50元).  跨省:如果对方是银行卡:转账金额的0.06% (也就是万分之六),最低1元/笔,最高12元/笔.

银行与银行之间的现金是如何流转的?

- - 知乎每日精选
***2015-08-05有更新***. 首先,题主说的「现金」,银行术语叫「现钞」. 银行术语的「现金」包含范围更广,有现钞,也有你账户下的数目字. A君将100万现钞存入X银行:X银行在A君的账户下贷记100万(增加100万);现钞进库房,第二天可能去柜台可能去ATM机,满足其他储户的提现要求.

黑客轻易入侵花旗银行

- Wuvist - Solidot
Visame 写道 "盗取超过200,000名花旗银行客户资料的黑客使用了一种极其简单的方法入侵. 此举被称作是近年来最大胆的一次银行入侵. 黑客们仅仅是简单地登录花旗公司的信用卡客户专区,然后把浏览器地址栏中自己的帐号替换成他人的帐号,便可顺利进入他人的帐号. 随后黑客们使用计算机程序重复这一过程.