商业银行多系统复杂环境版本发布自动化实践
作者：史新丽
来源：《中国金融电脑》 2018年第4期
金融市场的激烈竞争下，业务需求不断增加，上线速度加快，对银行科技部门在研发和测试提出了更高的要求。随着测试水平的逐步提高，项目管理日臻完善，质量管理已经达到一定的成熟度。然而，在进入测试阶段后，仍会出现很多影响交付效率的问题，比如测试自动化程度低、编译出包速度慢、版本部署步骤繁琐、发布频繁、手工操作较多和测试人员等待时间较长等。本文将主要针对测试版本发布过程中遇到的难点、痛点以及解决方案进行阐述。
一、当前发版面临的问题
目前很多金融机构设立了专门的测试团队，从流程上按照开发阶段和测试阶段进行划分。
1. 测试阶段面临的问题
在每次投产上线前的测试阶段，当大量的测试基线（测试版本）出现时，都会面临以下的问题：
（1）业务系统繁多，每个系统每天都可能会有多个版本的产出。
（2）各个业务系统的发版步骤均不同，步骤复杂，但重复性较高。
（3）各个业务系统涉及的测试环境复杂，每一次发版可能会涉及多个环境。
（4）以上是很多金融机构测试发布时都会遇到的共性问题，发版自动化的实施可以利用技术手段来避免人工重复性的劳动，降低操作复杂度，规避人员流动的弊端。
2. 在项目实施自动化实施方面面临的挑战
（1）每个系统的部署步骤不同，如何在不同中找到相同点。
（2）自动化脚本由不同的开发人员编写，风格不同。
（3）开发人员的流动性导致后续脚本维护困难。
（4）发版人员习惯使用手工操作，如何帮助其转变观念，普及自动化文化。
二、解决方案
1. 测试持续集成流程
当今为应对业务需求的快速变化，项目研发引入了敏捷的开发模式，持续集成的概念是敏捷项目实际落地的工程实践之一，它提倡尽可能将最早的开发产物提交到测试集成环境中，经过一系列自动化的方法尽早发现缺陷。从整体的研发过程视角上看，测试版本发布实质上可以归结到持续集成流中的一个重要环节。
由于银行项目对于安全运营有着较高的要求，并非所有项目都适用于敏捷模式，但敏捷的实践在非敏捷项目中也可以采用。银行以安全运营、质量提升为前提，从组织结构上设有不同的团队来分别进行开发和测试，按CMMI3 及以上行业标准的要求对每个阶段都有比较严格的划分和评审。开发阶段与测试阶段的衔接是测试版本的基线，测试基线变为进入测试阶段的一个标志物，后续测试遇到的操作均可以效仿持续集成的理念，纳入到测试持续集成流程中覆盖，从而解决版本发布的问题。
如图1 所示，绿色部分是本文主要关注的范畴。测试持续集成流所能解决的问题是，根据开发传递的测试基线，从配置库下载源代码，更新到编译环境中，进行自动化编译，构建测试所需要的成品，上传到成品库，测试从成品库下载，并采用自动化方式在多环境上进行部署，对于需要自动化测试的需求，可调用自动化套件进行分层自动化的实施。
2. 版本发布架构设计
测试持续集成流与持续集成相似，技术栈可以复用，目前持续集成工具有很多，Jenkins 是比较流行且满足要求的工具，它具有轻量级、扩展性强和功能全面的特点。以测试基线作为输入项，以Jenkins 为底层流程驱动引擎，在上层构建测试版本发布的界面以及其他管理模块。整体的测试版本发布架构设计如图2 所示。
由基线接入前置模块接收开发阶段传递给测试阶段的基线号，入库到基线管理模块，这些基线初始状态为“未执行”。由作业管理模块来定义每个系统的发布作业的具体操作，其本质为一系列脚本的调用。版本发布人员只能看到所负责系统的基线列表，并在此基础上点击运行、查看日志，完成每一次的版本发布操作。由Jenkins 连接模块来驱动Jenkins 执行作业定义的内容。对于执行完毕的基线，状态修改为“执行成功”或“执行失败”。基线部署如图3 所示。
3. 脚本标准化
前面阐述了测试版本发布模块的架构设计，但是并非有了总体架构就可以实现版本自动化发布，在实施过程中还会遇到很多困难，需要针对每个系统的部署脚本进行系统化的设计。
银行系统部署特点为系统繁多，每个系统的部署步骤较为繁琐，加之开发人员水平参差不齐，流动性较大，开发质量和后续维护的可持续性都是需要考虑的问题，脚本框架的开发势在必行。Python 是现在主流的脚本类开发语言，它具有跨平台、功能强大和扩展性强的特点，可选为脚本框架的开发语言。
在没有使用框架之前，开发人员使用Python 针对每一个系统的步骤编写脚本，虽然也可以实现相应功能，但是在输出格式和开发质量方面无法达到要求，且存在大量重复代码，维护起来相当困难。框架能够规范开发标准，简化开发过程，实现脚本开发的统一化。脚本框架的设计如图4 所示。
在构建了以上的框架模型后，脚本开发人员通常只需要按照语法要求编写配置文件就可以实现复杂的功能，开发周期大大缩短，代码质量也得到极大的提升。
4. 脚本集中管理
版本发布由自动化架构来触发驱动，但实际发挥部署作用的核心内容来自于部署脚本，这些部署脚本是真正的资产。由于测试阶段所覆盖的系统众多，每个系统涉及的环境较多，脚本散落在各个环境上，容易产生丢失或版本不一致的现象，因此在整体架构中也考虑了这部分的需求。在作业管理模块中，收集各个环境的配置信息，定期对各个环境的脚本进行上收，由统
一的脚本库管理，能够做到脚本的备份和追溯。脚本依赖的脚本框架一旦发生变更，在经过测试后可集中下发，更新到各个环境上，便于进行脚本框架的升级。
5. 自动化理念的推广
传统的发布流程为手工操作，尽管自动化发布能够缩短部署时长，自动化测试的理念深入人心，但行为的转变还需要一段时间的引导。首先要在自动化发布的工程方面严格把控，只有做到工程质量高，运行错误少才能吸引用户使用自动化工具。另外组织层面上也需要对自动化方面进行宣贯和鼓励，恰当地采用自动化率等指标作为衡量，能够有效起到积极的引导作用。为推动自动化发布的广泛使用，在版本发布架构中设计了统计模块，能够实时地对版本自动化发布的情况进行统计，方便查看自动化实施的百分比，失败率等指标信息。版本自动化发布的情况如图5 所示。
三、版本发布自动化方案实施效果
一整套的版本发布自动化方案实施以来，取得了比较明显的效果。测试团队所负责的80% 系统都已经实现了自动化发版，每月能够处理上千个版本的自动化发布，大大减少了重复劳动和人工干预，提高了发版效率。
持续集成工作流将在开发、测试流程中发挥更大的作用，贯穿整个工程研发的过程，向前延伸到开发阶段，向后推广到自动化生成投产交付包的应用中，对于每一个需求的部署以及交付包的投产做到全周期的滚动发布。
