大家好，我是来自工行软件开发中心的庞良，今天和大家交流的题目是在持续交付领域的建设分享。

今天分享的议题分四个方面：首先介绍一下我们在相关系统的建设的历程，其次介绍我们在工具链方面的建设的实践；然后介绍一下我们如何推动DevOps的变革。最后说明一下我们的整体目标。

第一个议题。工行这个版本体量相对是比较大的，所以我们的版本节奏也分三个类型。首先是季度版本，按每个季度开发测试投产，包括应用，主要是银行的核心业务系统，还有我们的Z/OS主机核心应用。第二个就是月度版本，这部分主要是针对直接发布的应用，开放平台分布式系统，还有上云的应用。最后一个是灵活投产的模式，主要是针对快速原型法，以及敏捷迭代这些发展的应用和开发。

为了支持这些不同节奏的版本发布的功能我们也开发了很多系统。在2008年我们开始自主题版本管理系统，后续逐渐研发和开放平台的版本开放系统，在2012年引进了CC代码管理工具，2013年开始做持续集成的研究。2014年我们建立了内部的智能运维平台，2015年开发了一套版本投产一体化、支持自动化部署的系统，在2015年完成了平台化以及DOCKER版本管理的功能，2016年探索DevOps在我们行应用的场景，2017年是扫描持续交付系统。2018年我们开始了持续交付的建设，并且完成了投产的运行，实现了上云以及传统版本的纳入流水线投产的功能，另外我们也开始引入了业界DevOps的评估，跟业界做了一些对标。

第二部分，关于工具链建设的实践。首先是源代码的分支管理的模式。我们的分支管理模型分为两个，首先是传统的月度版本的分支模型，主要针对并行版本比较多的场景。另外就是灵活阅读版本分支模型，主要是针对灵活投产的应用。这两种模式是并存的，传统的版本分支模型复杂度比较低，但是不够灵活。月度传统模式中我们需要配置特定的配置管理员，一旦月度分支版本建立起来，就需要专门的配置管理员管理这个分支，到交付的时间点，这个分支的所有内容基本上要全量做一个交付投产。如果有一些分支没有完成，或者有问题的话，要单独的做一些特殊处理，所以这个月度模式是计划性比较强的模式。第二个就是灵活的特性分支模型，我们不需要配专门的管理员，由开发人员自己管理，开发完以后直接提到测试分支，测试以后再提交到交付分支，如果测试不通过是不允许提交到交付分支的，所以这个交付分支相对来说是比较干净的，所以在交付的时候直接把分支交付出去就可以了。

下面介绍一下我们对原数据以及数据库版本管理的方式。以前工行就是以大型机主机为主，所以我们的整体架构是相对比较集中的，我们开发的语言基本都是用COBOL，数据基本上是用DB2，有五千多张表，效率可以接受，按单个程序、单个表的力度来管理。到了分布式的时代，分布式时代效率严重受阻，引进开源的产品做了XML方式管理DDL，引入开源，通过持续交付流水线，自动构建、部署、测试、交付，构建时，自动生成数据结构回写SEAS、审批不通过不能交付，总体原则是不能因为审批耽误了效率。

下面介绍一下我们的构建和构建云。构建包括了很多内容，有源代码到目标的转换，数据结构到DDL的转换，配置文件到配置中心K—V的转换。构建是一种依赖管理，MAVEN命令规范化BURDXML扫描，写入制品库，标识关联。构建是统一的入口，应用服务节点模型入口，版本目录标准化入口。构建是一种管控，引入黑名单开源JAR包，禁止构建；代码扫描不合规，禁止构建。原来构建分三层结构，改造成最新的微服务架构，把所有构建的模块进行了服务化的改造，另外把所有部署的时候构建的部署模式改成了容器化，通过容器化方便地进行扩充容。

下面介绍一下我们的持续集成。这也是采用了业界比较典型的流程，包括获取源代码和案例、自动化，编译部署，自动化测试，报警通知，获取邮件资源，自动化检查等等，也是采用Jenkins的流程。

下面介绍一下自动部署，这是我们自研的一个核心产品，采用的是WAS—SLAVE、Agent架构，三中心部署，三中心互通，分行、海外连接到数据中心进行操作。自动化部署工具也是跟制品库和容器镜像联动，实现版本预下载，丰富的标准租件，开发团队可定制部署策略，比如投产前的备份，投产后的策略定制，还有投产失败以后有一些恢复的操作。部署工具是支持每个应用根据它自己的特色编写自己的一些投产的策略，比如传输的规则、要执行的脚本，都可以在这个平台里面做一些可视化的拖拽。

介绍一下我们的制品库及软件分发。这也是我们自研的产品，SPMS，包括构建制品库、交付制品库，外购软件管理库，开源软件管理库。MAVEN库，容器镜像库，艰巨制品保存及制品分发功能，总分结构，双活节点。另外还具备了开源依赖管理信息库，就是构建扫描的时候会把很多的引用关系扫描出来，也是放到制品库。

持续交付流水线，也是在去年开始研发，也完成了投产，从构建到投产，串接多个子系统，全线可视化，实现线上线下联通，多类型流水线，持续交付，直接发布，紧急补丁，紧急变更等等。

下面介绍一下环境管理，我们认为环境管理是在持续交付建设过程当中不可逾越的大难题，以前每次运维出一些问题，开发人员肯定就会找运维人员。我们做了持续交付流水线以后，把后台很多系统DB掉了，很多通过流水线就展现出来了，相当于开发人员碰到的问题基本上都找到了流水线的运维开发人员，所以无形中也是背了很多锅，我们认为这个环境管理也必须要做一个整体的考虑设计。

目前我们自己内部有一个功能非常丰富的智能运维平台，这个平台功能非常多，不一一介绍了。包括了统一运维的门户，运行监控平台，应用运维平台，运维的分析平台，还有CMDB等等。CMDB分两大部分，一个是基础设施部分的CMDB，一个是应用部分的CMDB，我们做了隔离分开管理，应用的CMDB是分在交流配置中心里去，后面会有一个介绍。另外这里有一个体会，让CMDB的数据保持鲜活不是件容易的事情，我们做了很多工作，包括事前检查控制，事中的自动登记，还有事后的自动扫描等等，但是做下来感觉还是比较困难，有些手工必须要有的。

接下来介绍一键式环境克隆，因为我们的版本比较多，多版本环境的并行开发使用，环境需要基于标准化建设，例如可域名访问，信息进入CMDB，独立部署等等。这个一键式环境克隆，包括了基础环境的搭建，海上登记，还有配置文件的自动替换，启动数据服务等等。另外在环境自供应前有一种折中的办法，一种标准的版本包级标准的基础含量，测试环境随时可生成。

下面介绍文档在线管理，文档我们认为这是在现阶段标准化做的不够好的地方，是一个不可避免的问题。因为我们岗位分工很多，每个岗位的理解也都不一样，所以很多时候会产生一些分歧，我们整合了不同维度的文档，把这个文档做了一个模板化，减少一些错误。这个文档管理系统也是作为一个独立的版本实体，可以脱离版本包在三中心里流转。不同的岗位可以提前订阅，提前阅读了解项目的情况，各个环节可以提前修订文档，减少交接的过程。这个文档在线管理实质上我们也是作为过程产品在开发，最终的目标还是希望去文档化，最后能把文档里面的东西，标准化、转化成脚本，后面就会慢慢消灭掉文档。

下面介绍一下配置中心建设。前面说的CMDB，我们提到把应用版本相关的配置提炼出来，形成了配置中心。配置中心包括的内容主要是有系统软件配置，应用网络特性配置，应用软件配置。从另外一个维度来说，也可以分为静态配置和动态配置。在投产的时候要通过重启服务器生效的，把它规划为静态配置。动态配置是不需要重启服务器，是随时生效。部署静态配置管理，环境基线静态配置管理，应用动态配置管理，基于APOLLO开源工具实现实现。

下面介绍应用服务节点模型，这是我们内部的概念，它代表的意思是一个应用服务节点代表了一个应用的某种服务功能，比如数据库的节点，批量的节点，应用程序的节点。一个应用在它新增以后必须要先建立一个应用服务节点，描述它应用的整个的逻辑的架构。后面的整个流水线，包括从开发到生产的都会按照应用服务节点的模型去构建，去打包，交付，部署，也会按照应用服务节点这个模型去管理应用级的CMDB。通过这个应用服务节点，开发测试和运维不同的群组，互相沟通起来就会采用相同的语言，大家的沟通效率就会非常高，这是整个流水线流程管理优化里非常核心的设计。

下面介绍自服务统一管控平台，这是我们推动自服务的一种手段。包括标准环境的一键式供应，里面有操作系统、中间件、数据库模板，可以实现标准环境的供应。基于智能运维平台及PaaS平台的操作系统或容器实现自供应。原来是基于多入口方式的，由智能运维平台，还有UDSP自主供应，物理机需要手工供应，PaaS平台可完成自供应。总体的原则，我们希望能够让开发做到谁开发谁运维。

上面介绍了工具链的建设，实际上工具链的建设，我们的体会是，因为业界有很多开源产品，工具链建设不是最难的部分，难的部分我们感觉还是在整个系统的推广过程。比如我刚才听到自助化的过程，很多开发部门很抵触，以前不是我自己做的事情，为什么现在变成我做了。以前环境准备，要准备好几天，我还可以多争取几天做开发，为什么现在变成我来做，所以难度是在于一些理念的变化。这个是让我们最头疼，整个团队越大，你的变革推的越困难，所以我们也是想了一些办法推动这些变革，下面介绍一下我们的措施。

首先，是努力改变开发的模式，对于一些流程比较长的，进行一些优化，从按项目管理改变成按产品管理，所以我们现在基本上是走的产品经理这种机制。需求不明确要反复澄清，给大家灌输很多理念，请外面的教练进来，一定要把这个需求写出来，这都很重要。需求没有细化，版本计划周期太长，针对这种问题我们是把需求进行条目化管理，建立一个需求池，排列相关的优先等级。另外也整合了灵活投产的窗口，现在每个应用可以申请，把自己的应用定为灵活投产的应用，这样就可以不按照月度或者季度的节奏发，可以随时发，我们的流程还是比较严格，你不申请生产不会让你投，你申请的投产作为灵活投产，生产通过流水线，现在也可以做到无人职守，定时投这个版本也是比较受欢迎的。

第二个是完善团队，完善组织架构，DevOps千人千面，实际情况差异都很大。就像康威定律说的，不同的企业有不同的组织架构，不同的组织架构决定了这个企业系统设计的架构，所以背景不同、历史不同，解决方法不能相同。我们以前主机架构延伸下来的很多开发团队也是规模比较大的，几十号人一个团队，到了现在开发平台架构转型以后，基本上也是按照小团队的模式去倡导，重组这个团队，现在十几个人一个开发团队，这也是硬性的要求。另外，我们也跟开发倡导工具链是基础，但不是全部，各类流程和方法也需要改变，例如源代码管理方式、开发团队的工作习惯。另外，实践是检验真理的唯一标准，论证和想法很多，通过实际的数据打通开发，加入我们的变革。我们还努力优化整个应用架构，因为以前延续下来的主机的应用额度很高，无法做到灵活投产，大部分也是主机的核心应用，这些也是我们重点要解耦的应用，但是这个难度可以说是非常大。对于新增的应用，现在基本上也是建议大家往分布式、微服务的架构做转型，毕竟这种系统对我们的持续交付理念还是比较契合的。

最后一个议题，给大家描绘一下我们的整体目标。我们希望能够做到工具链不断完善，大部分自动化，做到开发测试投产全线贯通，让开发的方式逐步的优化改变。另外，我们还要兼顾大版本规划以及持续交付，做到核心系统大版本，求稳定，少变更，毕竟我们也是应用行业，监管的要求跟互联网也不太一样。对于外围、对客系统灵活版本、多变化。最后是上云和传统环境齐头并进，最终合一。各个企业也有自己的一些现状、文化、特点，所以也是建议大家根据自己的实际情况制定一些合理的方案，也祝愿大家能够早日建立起自己的高标准的持续交付体系。

我今天的交流内容就到这里，谢谢大家。