【DevOps进行时】持续交付广义流水线探索 – 农行DevOps实践之路

标签: DevOps 公司博客 案例 TFS VSTS | 发表时间:2020-08-09 21:13 | 作者:徐磊
出处:https://devopshub.cn

持续交付流水线是DevOps落地的重要工程实践,但是业界普遍把持续交付流水线建设等同于CI/CD,很多人觉得部署好Jenkins,配置个自动化job,能编译,能部署,能跑自动化测试就搞定了。其实真正的持续交付流水线远不仅仅是这些内容,它应该包括从需求/创新的提出,到功能架构设计,计划跟踪,开发编码,编译打包,测试验证,投产上线,再到将实现的功能让用户使用起来的全过程。

为了区分业界普遍理解的CI/CD流水线概念,我们将真正意义上的持续交付流水线定义为【广义流水线】,对应业界普遍理解CI/CD流水线并称之为【狭义流水线】。【广义流水线】的概念在中国农业银行一直都是主要的DevOps实施方法论指导。

农行是典型的国有全国性大型银行,研发规模大,涉及部门和人员多,系统复杂。因此农行研发中心很早就非常重视研发效能改进,从组织架构,人员角色,系统架构,管理方法论和研发工具链各个方面持续投入。英捷创软科技(北京)有限公司(下简称LEANSOFT)自2015年开始与农行研发中心合作,与项目管理办公室对接,为研发中心3000多研发人员提供基于微软Team Foundation Server (现已更名为Azure DevOps Server)的项目过程管控体系规划设计和定制化服务,持续参与农行研发中心的研发效能改进过程,助力农行敏捷、DevOps能力建设。这个过程可以大体分为三个阶段。

第一阶段
试水研发端到端全流程管理 – 农行互联网金融战略三大平台工程

2015年,为了适应国内金融业的快速发展,中国农业银行通过多年的总结、实践,探索出来的互联网三农金融服务有以下五个模式:

  • 第一就是电商加涉农;
  • 第二是商业银行线上化服务;
  • 第三是以农业的龙企业为代表的农业产业链加在线金融的模式;
  • 第四是以农产品交易市场加供应链金融;
  • 最后是P2P、众筹。

相应的,农业银行形成了「三大平台五大产品线」的长期战略。

  • 三大平台分别是社交生活平台,电子商务平台,金融服务平台;
  • 五大产品体系就是网络支付,网络融资等。

LEANSOFT团队作为支撑农行互联网金融三大平台五大产品线建设工程的DevOps研发工具链技术支持团队,与当时项目办组建的重点工程支持团队一起,完成了这一重点工程的研发管理和工程效能改进支撑工作。

在这个过程中,我们探索了使用微软Team Foundation Server支撑研发端到端的完整流程,梳理出了从立项,业务需求,工程拆分,编码开发,自动化构建和发布,测试和缺陷管理到QA质量保障的7个关键步骤,取得了非常好的实践效果。

这个项目也在2016年的微软技术大会上作为KEYNOTE主题演讲案例重点推介给全国的技术社区。

互联网三大平台工程是农行内部第一次用一个工具将研发过程端到端的管理起来,相比较之前使用多个工具串接的方式,这种方式降低了工具之间集成的工作量,让管理人员和开发人员可以更加关注研发流程业务本身,同时也可以天然地完成研发数据的端到端贯通。

在这个项目中,团队还探索使用了微软TFS所提供的CI/CD流水线完成了代码的自动化编译和自动化部署,大大降低了团队花费在频繁部署测试环境上的资源消耗,同时也确保了测试环境部署的可靠性,为研发过程的提质增效提供了有力的工程实践保障。

在这一阶段,虽然没有提及敏捷和DevOps的说法,但是在项目推进过程中已经开始自发地使用敏捷和DevOps中的很多理念,方法和实践,为后续农行在敏捷和DevOps转型上的进一步探索打下了基石。

参考文章:

  • 大喵手绘|神秘的互联网金融项目是如何进行质量管理的
  • 手持利器,心无畏惧——TFS深度体验报告

第二阶段
深度探索精益敏捷研发模式 – 农行春天工程和其他

有了第一阶段的探索,在农行研发中心内部的很多团队看到了敏捷和DevOps模式的优点,开始进行更加深入的试验。在2017年下半年,农行研发中心应用开发二部启动了移动营销平台建设项目,因为这个项目计划在2018年春季发布,因此也被冠名为“春天工程”。

春天工程以三大平台为依托,通过构建营销宝,营销派,营销管家和金融小店四大产品为目标,试图利用互联网的模式为农行客户经理以及全体员工提供移动营销工具,借助手机,PAD,掌上银行,微信,小程序等各个渠道推动金融产品的销售。因为更加贴近终端用户的业务属性,开发团队希望探索使用敏捷开发模式来运作这个项目。

春天工程从一启动就受到了研发中心项目办的特别支持,建立了以内外部教练为核心的敏捷试点支撑体系,通过为试点团队不断提供培训,教练,贴身辅导等方式指导开发团队一步步建立迭代式开发节奏,同时持续收集和整理团队的实践,进行内部外部的成果推介。这个敏捷试点支撑体系不仅为春天工程提供了强有力的支持,也为农行内部创造了更好的敏捷土壤。

这个过程中,LEANSOFT团队也为项目组提供了一系列的敏捷指导和DevOps工具支持,包括参与团队的日常敏捷活动,梳理Kanban和站会流程,优化可视化板的结构,协助团队建立CI/CD流水线,迁移和梳理Git代码库结构,设计和配置基于特性分支的配置管理策略,指导团队使用微软TFS所提供的拉取请求(Pull Request)功能完成代码评审和代码质量验证,自动化编译,打包,测试和部署。我本人也作为外部教练参与了团队的日常敏捷活动,持续指导团队建立起迭代节奏。

这些实践对于支撑团队从传统研发模式转换到敏捷研发模式起到了非常重要的支撑作用,从需求跟踪,流程管理,迭代开发,测试管理和监控反馈五个方面确保了春天工程敏捷试点的成功。

春天工程虽然整体规模上没有互联网三大平台工程大,但是在敏捷和DevOps实践探索的深度上更为深入。团队从Scrum和Kanban做起,经历了3个月的持续改进,完成了相对稳定的Kanban管理流程和可视化板的设计,再通过将测试团队引入项目组实现迭代内的持续测试,最终实现按照用户故事粒度的持续交付和前期产品设计阶段更为合理的需求到故事的拆分体系。整个流程的建立耗费了超过8个月的时间,是一个非常典型的敏捷团队试点转型实例。

参考文章:

  • 农行基于TFS工具的敏捷转型实践
  • 来自农行软开的看板站会秘籍和敏捷转型经验
  • 【DevOps+LIVE视频】中国农业银行敏捷转型和看板秘籍分享
  • 敏捷可以这么玩:基于TFS电子看板的Scrum管理实践
  • 【过程瞭望】从理论到实践,平台部敏捷践行落地
  • “五型五秀”:满眼生机转化钧,天工人巧日争新 ——C3“全场景配置管理+持续集成”探索实践之路
  • 15分钟帮你把“镜(kan)子(ban)”擦干净
  • 一种适用于大规模应用系统双模研发的GIT分支模型(上篇)
  • 一种适用于大规模应用系统双模研发的GIT分支模型(下篇)
  • 如何在项目研发中吃着火锅唱着歌?
  • 某银行大型管理系统端到端持续集成和交付实践
  • C3端到端全流程敏捷研发转型之路大揭秘

 

第三阶段
全面推进DevOps转型和全行工具链贯通 – 信通院DevOps评级工作

第一阶段农行研发中心通过互联网三大平台工程的契机建立了端到端研发管理的框架基础,第二阶段的春天工程中又从深度上验证了敏捷和DevOps的模式,证明了这些实践可以在传统银行的组织环境下实现更为快捷的交付速度和更为灵敏的业务响应能力。

在2017-2019年之间,农行研发中心一直在推进工具收敛的策略,将原先散布在不同工具上的流程逐步收敛至TFS这一个平台上来,这个过程中另外一个非常重要的工程实践就是集中构建流程的建立。

集中构建流程要求所有需要投产上线的软件包必须通过TFS的自动化构建进行创建,运维部门只能通过受控的集中存储获取投产包。这一流程在TFS上的落地,确保了研发和运维之间建立投产数据包的唯一可信源,为后续的DevOps全流程贯通打下的又一个坚实的基础。

LEANSOFT团队在协助农行研发中心推进集中构建的过程中,充分发挥了微软TFS内置的CI/CD流水线的跨平台构建集群管理能力,创建并管理了上百台构建机组成的构建集群,支持了包括Windows, Linux, Mac在内的不同操作系统上不同技术栈(包括:Java, C#, JavaScript, Python, c/c++等)的自动化构建,静态代码检查,代码安全性扫描,单元测试执行和结果收集,以及不同环境下的部署流水线设计和实施。

基于以上成果,农行研发中心于2019年启动了由信通院制定的《研发运维一体化(DevOps)能力成熟度模型》三级评估。在启动评估的初期,LEANSOFT团队参与了由农行研发中心项目管理办公室牵头进行的农行DevOps研发工具链建设体系框架的制定,通过DevOps咨询产出了【DevOps工具链规划广义流水线】规划框架视图。

对于农行研发中心这样规模的研发类组织,内部部门繁多,人员角色复杂,流程复杂且环节多,非常需要一个整体的规划框架统一所有人的理解,这样才能确保DevOps实施的成功。

【DevOps工具链规划广义流水线】规划框架包含了三横一纵四个要点:

  • 三横。主要包括第一层的项目/产品级管理(PM),第二层的工程管理(SE)和第三层的工具和环境管理。这三个层次分别覆盖了组织中不同层级的管理诉求:第一层主要覆盖组织级管理诉求,侧重于组织资源优化,投资组合和创新管理;第二层主要关注部门,项目/产品级的管理诉求,侧重于过程改进,质量控制和效率提升;第三层关注具体的实现方式,侧重于各个领域工具的适配和集成,为第一和二层的管理诉求提供足够的支撑。
  • 一纵。主要体在研发度量数据体系化管理上,在以上三层中我们要尽量将管理流程数字化,并通过需求这条主线形成贯穿所有过程的数据链条,为上图中的组织级,部门级,项目/产品级,团队级和个人级仪表盘和数据分析视图提供数据支撑。实现工具无关的管理度量体系。
  • 这其中的一纵其实是DevOps工具链建设中非常关键的一环,我们都知道DevOps三步工作法,这个DevOps实施方法最早在《凤凰项目》这本书中提出后已经被业界公认为是非常有效的DevOps实施落地指导思路。三步工作法的第二步就是建立反馈,而研发度量数据体系其实就是为团队提供反馈最重要的一种方式,也是赋能研发团队进行自我改进中最重要的一环。

在农行研发中心的DevOps工具链建设过程中,LEANSOFT团队配合项目办的度量指标设计团队一起,围绕交付交付效率、交付质量和交付能力三个维度,一共完成了43个指标的设计,规划,实施和数据展现。

在度量平台实施过程中,LEANSOFT团队采用了自助研发的“软件交付效能仪表盘(Proejct Dolphin)”解决方案,围绕“DevOps通用数据模型”建立了一套专门针对DevOps研发类数据的可扩展,可插拔的度量数据抽取平台。解决了不同角色的人员对数据视图的不同诉求下,又可以保证数据模型相对稳定演进的问题,满足了DevOps评级过程中对度量指标的各项要求。

经过团队的共同努力,中国农业银行研发中心在2020年6月19日顺利通过 DevOps 标准持续交付部分的 3 级评估的项目,相关项目以及项目组分享的实践文章链接如下:

1)信贷中台项目
助推数字化转型,农行信贷中台 DevOps 转型实践
2)个人网银项目
线上金融 DevOps 排头兵:农行个人网银系统实践
3)分布式应用互联平台(AIR)项目
助力技术中台数字化转型,探索农行 DevOps 实践之路
4)增值税进项税管理项目
当“微服务”遇见 DevOps,农行增值税进项税“1+1”研发模式
5)金融小店项目
农行金融小店不可不知的 DevOps 测试自动化之路
社交营销与 DevOps 共舞,农行金融小店 DevOps 落地实践

参考文章

  • 【DevOps进行时】接口自动化测试之内功心法
  • 【DevOps进行时】农行信贷中台用户故事地图落地实践:激发沟通火花,洞查真实需求
  • 阿捷外传之Git代码统计
  • 【洞见】DevOps专题|DevOps农行本地化实践探秘
  • 数据驱动,让 DevOps 看得见,摸得着
  • 重磅!中国农业银行多个项目通过 DevOps 持续交付标准 3 级评估,相关项目能力达到国内领先水平!(有本图)
  • 度量驱动 DevOps 转型:中国农业银行 DevOps 度量体系建设实践浅析

作者简介

英捷创软科技(北京)有限公司 LEANSOFT
首席架构师 | 资深DevOps顾问 | 微软最有价值专家MVP
徐磊

中国农业银行研发中心
项目管理办公室 DevOps实施牵头人
苏小彦

相关 [devops 持续交付 广义] 推荐:

【DevOps进行时】持续交付广义流水线探索 – 农行DevOps实践之路

- - DevOps 博客
持续交付流水线是DevOps落地的重要工程实践,但是业界普遍把持续交付流水线建设等同于CI/CD,很多人觉得部署好Jenkins,配置个自动化job,能编译,能部署,能跑自动化测试就搞定了. 其实真正的持续交付流水线远不仅仅是这些内容,它应该包括从需求/创新的提出,到功能架构设计,计划跟踪,开发编码,编译打包,测试验证,投产上线,再到将实现的功能让用户使用起来的全过程.

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

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

探路持续交付

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

持续交付模式

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

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

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

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

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

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

drone | CI/CD | 基于容器技术的持续交付平台

- - yiyun's Blog
Drone 分为 Server 和 Runner 两部分. 需要与 源代码控制 相结合, 这里与 GitHub 相结合. You can install a single Docker runner, or install the Docker runner on multiple machines to create your own build cluster..