【DevOps进行时】某银行大型管理系统端到端持续集成和交付实践 | IDCF

背景

传统的银行IT系统研发流程从需求提出到产品交付往往具有较长的研发周期，纵观银行当下面临的市场环境，个人信贷消费升级，资管需求旺盛，普惠金融成为国家战略，来自银行同业和互联网金融的压力扑面而来，谁先推出符合市场需求的产品谁就占领了先机，对银行IT研发的快速交付能力提出了新的要求和挑战。

传统银行IT系统研发过程中的弊端主要体现在研发流程不连贯难追溯、人工处理效率低时效差、缺乏有效的代码审查机制、人力资源浪费等，针对上述问题，我们基于持续集成、持续交付的理念，设计了针对某银行大型管理系统（下称C系统）的CI/CD流水线，开发了一系列核心组件，基于TFS (现已改名为 Azure DevOps Server)实现了端到端、线上化、全自动的持续交付。

一、CI/CD流水线的设计与实现

C系统是某银行重要的大型管理系统，具有多团队协作、多项目并行、多技术体系并用、多产品/模块协同、多环境并存、多时点交付等特点，是一个典型的银行大型IT系统。我们以C系统为试点，基于TFS，设计了从需求管理、任务分配、分支建立、代码提交、版本合并、自动化构建发布到自动化测试的覆盖研发全流程的持续集成和交付流水线。开发人员通过全线上操作发起版本发布申请，将代码收集、版本核对、构建发布等重复性工作自动化、线上化，提高了版本交付的效率与质量、释放了人力资源。

图1 持续集成和交付流水线模型

1.1 自动化代码静态扫描

代码静态扫描是控制代码质量的重要手段。对于C系统来说，原有的人工触发全量检查方式是一种被动的事后检查策略，在发布生产环境前检查，每次检查至少需要3个小时，且需要人工甄别增量违例，时效性差、工作效率低、修改成本高等问题突出。

为解决上述问题，我们深入研究了TFS API和JTest、CChecker等静态检查工具，通过文件哈希值比对等技术手段，对代码合规检查组件和邮件通知组件进行了深度定制，形成了一套按需增量检查+定时全量检查相结合的代码合规检查策略，并能够向相关负责人精准发送违例代码通知。

表1 代码合规检查调用的TFS API列表

我们将代码合规性检查集成到持续集成和交付流水线中，在开发人员申请将代码合并到测试版本库或准生产版本库时，自动触发代码合规性检查步骤，并自动解析检查报告，若存在新增违例，则禁止代码合并，并向代码提交人发送邮件通知。

图2 分支策略中配置的代码合规性检查

图3 代码合规性检查存在新增违例的日志信息

1.2 代码强制评审

代码评审主要包括两方面内容：一是C系统由多个模块构成，每个模块由不同的开发人员负责，当出现跨模块的代码修改时，须由该模块的负责人评审改动内容的准确性；二是系统中存在一些公共配置文件，这些文件改动后可能会对整个系统产生影响，须由资深的系统研发人员进行评审。

我们借助TFS拉取请求中的审阅者功能，设计了满足C系统特点的代码强制评审策略，有效避免了误审、漏审、甚至不审等弊端。

我们首先在TFS中创建了C系统各模块的开发人员团队，并在分支策略中配置了各模块对应的代码路径。

图4 分支策略中配置的模块负责人

当开发人员提交代码时，TFS会自动判断是否存在跨模块的代码修改，并在拉取请求的审阅者中自动添加模块负责人作为必须的审核人员，只有通过审核才能进行后续的代码合并。

图5 代码合并时的强制代码审核

1.3 持续集成持续交付

持续集成持续交付是提高研发效率、保证产品质量至关重要的一环，我们编写了一系列构建组件，通过TFS进行组件编排，完成不同环境的持续集成和交付需求。

图6 TFS构建中的组件编排

C系统前台使用java语言开发，以一个完整程序包的形式进行发布。对于日常的研发，将构建发布配置为定时模式，每周一至周五12:00和18:00定时自动构建发布，满足日常测试需要。

图7 定时构建发布配置

对于时效性强的敏捷类项目，将构建发布配置为实时模式，每当有代码提交时便触发构建发布，测试人员可及时介入，缩短开发测试周期。

图8 实时构建发布配置

C系统后台功能使用c语言开发，运行在AIX平台，无法直接使用TFS的构建功能，经过一系列的技术攻关，我们借助Jenkins自主实现了一套c程序构建发布的方法，解决了TFS Agent不支持AIX平台的技术难题，统一了C系统前后台的构建发布流程，为开发人员提供了简约一致的使用体验。

图9 基于AIX平台的C程序构建流程

c程序具有相对独立、依赖关系弱的特点，所以均采用由开发人员自主触发的实时交易构建发布模式，每个开发人员可按需独立发布程序，在构建参数中填入待发布的程序名即可。

图10 C程序自主构建发布

1.4 自动化测试

版本质量是研发的根本落脚点。我们构建了基于Ant+Junit+Selenium的功能测试框架，将测试流程集成到持续集成和交付流水线，实现了业务测试版本和准生产版本的回归测试，每日定时执行业务核心流程案例，缩短了版本验证时间，提升了投产版本的可靠性，有效降低了投产风险。

二、端到端的版本交付流程设计与实现

2.1 需求条目化和开发

项目经理从项目的角度，以“项目->模块->功能->任务”结构对需求进行条目化拆分，录入TFS，由项目组成员完成任务认领。随后基于各自的任务开展需求分析、设计、开发和测试等工作。

图11 TFS工作项管理层次

图12 TFS工作项示例

在TFS中配置开发分支自动编译，当TFS检测到新的提交后，获取代码并自动编译，若编译失败，则会自动向代码提交人发送邮件通知。

图13 TFS开发分支自动编译配置

2.2 测试版本发布

图14 测试发布总体流程

开发人员通过TFS工作项和Git的拉取请求（pull request）功能申请将改动的代码合并到测试分支。

图15 TFS工作项申请Git分支

图16 TFS创建拉取请求页面

配置管理员在TFS中对测试分支配置分支策略，主要包括：

• 必须使用拉取请求的方式向测试分支提交代码
• 所有拉取请求都需要经过至少一个人审阅
• 所有拉取请求都要关联工作项
• 配置分支合并时触发的预编译定义
• 配置代码审查人员

图17 TFS分支策略配置页面

在TFS提交拉取请求后，可以在web页面查看拉取请求状态，包括必须满足的条件、链接的工作项、审阅者、变更内容等，所有条件满足后即可完成代码合并。

图18 TFS拉取请求页面

完成代码合并后，会自动触发TFS中配置的程序自动发序包的部署。

图19 C3前台自动部署配置

2.3 投产版本发布

图20 投产发布总体流程

在TFS中创建投产团队，从系统的角度，以“系统->窗口->职能组->投产内容”的逻辑层次管理投产内容。开发人员通过工作项发起投产申请，填写投产内容并通过TFS文档库管理投产文档。填写完成后将投产申请指派给配置管理员进行审核。

图21 TFS投产团队工作项

配置管理员根据投产日期创建准生产分支

图22 配置管理员创建的准生产分支

开发人员申请将已完成测试的待投产代码合并到准生产分支

图23 创建合并到准生产分支的拉取请求

拉取请求预编译、评审等工作与测试发布流程一致。

完成所有待投产内容到准生产分支的合并后，配置管理员在TFS中创建投产标记（基线），基于该标记触发准生产版本的自动构建，生成投产包，发布到准生产环境供开发人员进行投产前的最终验证，验证完成后在投产窗口将程序部署到生产环境。

图24 TFS创建标记页面

三、总结

基于TFS的端到端持续集成和交付流水线在C系统中的正式应用实现了研发流程自动化、线上化、可追溯的目的，提高了系统研发效率、保证了研发质量、释放了人力资源、缩短了产品交付周期，是银行大型IT系统研发模式转型的一个典型实践。

银行IT系统研发流程的DevOps转型任重道远，是一个渐进式的过程，我们会对流水线模型进行持续改进优化，不断适应业务和技术的新需求，探索出一条满足银行IT特色的DevOps之路。

来源：IDCF社区

作者：葛江浩、宋绍磊、王丽敏