背景
传统的银行 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 社区
作者：葛江浩、宋绍磊、王丽敏