企业级研发团队的交付效率提升之道

贾晨

作者简介
王青，JFrog 中国首席架构师，信通院 DevOps 标准工作组的成员， GOPS 金牌讲师， Musp 案例100大会级联主席，多次在国内各大技术社区发表文章和演讲，例如 InfoQ、高效运维社区、51CTO等等，十多年的研发、DevOps 经验。

各位好，感谢大会的邀请，也非常荣幸在周末来跟大家分享一些经验和实践，今天的题目给企业级研发团队的交付效率提升之道。我是王青，负责 JFrog 国内技术团队。

今天的内容主要分三块，

• 低效能的制品管理占你整个研发效率会浪费多少时间;
• 我们如何用统一制品管理的方式提升整个研发效率，降低浪费的时间，提升效率;
• 第三个现在业界很火的怎么做安全漏洞扫描，对于开发、运维、安全来讲已经是不容忽视的问题。

低效能的制品管理浪费了多少时间？

我们先看一下低效能制品管理能够浪费多少时间。现在进入了一个什么时代？我们制品包总量数量都呈现爆炸的时代，什么意思？最开始的时候可能程序员要写JAVA、C、PYTHON，那么随着技术的发展，容器化，前端也大部分开始用Node.js进行开发，还有移动端，有GO，有各种语言的种类是越来越多，除了种类越来越多，其实我们制品包由于我们交付速度越来越快，那么企业快速发布，互联网公司都是天下武功为快无破，发布越快构建出来的制品越来越多，所以在这种情况下传统的制品库我们就管理不了，会带来很多局限性，现在看传统制品管理现状是什么样？

我们也拜访了很多企业，我们本身也有大概5000家的企业用户，那么我们看到他们在落地 JFrog 之前是这样的状态，在公司内部其实统一代码库是最简单的，然后统一持续集成，不管是用 Jenkins 还是封装 Jenkins，那么大家其实都在做统一持续集成这件事情，然后统一部署也是相对来讲容易标准化的事情，所以在现在的企业现状来看，基本上代码库持续集成、持续部署这块基本上已经统一了或者说已经走向统一的路程了，但是制品管理一直是处于混乱的状态，比如说很多公司把构建的挂包放到单独NEXUS仓库，MAVEN，然后有的公司放到FTP这个仓库，现在如果这个业务要上容器，那你还要搭建一个单独的 Docker 兼容中心，像一些兼容中心，这样你会发现一个问题，从企业角度制品是没有统一管理的，我虽然统一管理其他的组建过程，但是在这里很乱，从运维视角来看不仅从FTP拉一个包做部署，还要从 Docker 镜像去拉包，那么对他来讲里面就存在很大风险，最大的两个，第一个版本被篡改，那么之前应该是两年前有一个银行出现过版本被篡改导致线上的事故，造成了很大的影响，相关的责任人都要承担这个结果后果，还有权限控制，怎么对接不同的库必然要打通不同的权限，这个也是非常的麻烦。

其实跟制品管理相关的时间浪费，我们做了一个用户调研，也是一个总结，在一个迭代中，那么讲它是在160小时左右的迭代，160小时除以8是四周比较长的迭代周期，那么在四周里面其实研发包括运维发现大家都很普通加班，谁也没有闲着，大家仔细去梳理这一周发生的事情，哪些在敏捷里面的概念，什么是价值增加的活动，然后一共花了160个小时，哪些是浪费或者是等待的时间，我们把这些浪费等待的时间梳理出来，基本上跟制品跟这个包传递，包从创建到测试到交付给运维到部署，跟包相关的浪费时间可以占到40个小时，这个你看了可能觉得很吃惊，基本上四分之一时间都被浪费了，浪费在什么地方？比如说浪费等待确认版本，然后提测的版本不可用，由于我们的制品上没有一些信息，信息缺失导致开发和测试沟通出现了瓶颈，测试测错了包，部署可能部署错，另外引入高压漏洞造成了版本退回。

如何统一制品管理，提升交付效率？

既然看到制品管理有这么多可提升的地方，我们就提出了一个高效能制品管理的方案，那么这个方案基本上咱们我刚才也看了信通院的参评的公司基本上都是我们的用户，非常好。制品库管理这块基本上我们是提供能力非常高，落地JFROG 制品库达到四级以上的标准，那么简单来讲做什么事情？可以看到这是研发测试区，这是生产区，我们对于大一点公司研发和生产是分开，特别是金融企业，这就造成一个问题，研发和生产之间有一个屏障，然后这里划了两个制品库，能够提升金融审批的复制，打破环境之间的屏障，那么另外我们可以看到统一制品库的管理，你不管用什么语言，所有语言包都存在一个地方，比如说MAVEN、NPM、苹果、安卓这些都是存在一个地方管理。

那么首先第一个通过制品管理，大概可以减少了76%时间浪费，把疑似迭代中工具包相关浪费时间降低到9个小时，首先统一制品管理，然后在制品上我们要进入，不管用什么方案，不管用什么产品，制品本身一定要有源数据来描述它，这个制品本身是自描述的状态，我这个制品不管它摆到哪里，那么任何人上来看都知道这个制品从哪里来，谁构建，有什么需求，做了什么测试，然后要送到什么地方去，自描述，不需要沟通，这样才能够实现自动化。那么一切流程需要人工沟通才能走下去的流程，我们叫做推动式持续交付，很多公司是属于推动式持续交付，我们目标是要把推动式的持续交付变成流动式的持续交付，我们也是JFROG提出了叫做流动式持续交付的概念。

统一制品管理之后，可以看到我们支持了所有语言仓库基本上，像NPM还有苹果、安卓、GO，这样首先对于谁来讲受益最大，首先第一个受益是开发者，假如我是开发我要新建一个Maven项目，当然我定义不许依赖所以要找管理员给一个仓库，那么这个时候在制品库里面直接给它一个仓库地址直接拿了可以用，第二个受益是运维，运维会要求所有研发不管用什么语言开发都交到这个地方，都存在制品库里面，专业统一制品库，不管是哪个团队，地方在北京还是在国外，把制品交到咱们约定好的固定地址，我定期来取就可以了，就这么简单，不需要人工沟通。

搭建好仓库之后要进行命名规范，我们提出一个概念叫做四部命名规范，我们提过四个上限的定位来唯一描述你这个包唯一地址，那么首先是团队，团队的话很好理解，跟你组织相关，比如说你是开发你公司内部产品的，然后技术你用了什么语言，比如说 Docker 或 Mvn，这里面我们推荐一个成熟度，成熟度什么意思？我听了上午农行的专家介绍，他们用了制品晋级这个概念包括上午PICC都提到了晋级的概念，非常好，这个也是社区DevOps最佳实践制品晋级，如果你的公司内部还没有做晋级，那么要计划开始做，那么晋级可以从开发仓库然后升级到准生产部然后到生产，然后最后上线咱们的物理位置了，比如说北京、上海、深圳，通过这四个维度可以定义一个包的坐标。

那首先我们定义好仓库的坐标规范之后，我们再来看一下，其实每一个像大一点的公司，这个是金融客户，金融的一个大企业，那么他就需要非常清晰和组织结构能够映射上的组织关系作为制品管理的方案，那么在这样公司内部它交付制品包的时候按照这样层级目录去摆放，这样显得就非常的清楚。大家知道在大一点的公司特别是银行、保险、证劵研发和运维都是不同的部门，所以有了这么一个规范之后，可以看到所有研发按照自己的路径把自己交付包摆到在正确的位置，运维定期按照契约过来取，然后测试也是按照契约按照规划好路径过来取包测试，测试完了放到对应地方，运维来取包进行部署，这样就会给咱们开发测试三个团队打通包交付的流水线，包传递的通道，所以如果是银行比如说运维来看，我看到这个仓库的架构我就会非常清楚，我要布哪个部门开发到哪个产品，然后这个产品在什么地方是非常清楚的。

那从成本来看之前由一个人维护，至少要一个人维护Nexus仓库，维护一个NPM、MAVEN、DOCKER维护一个MTP等等这些仓库，花一个人/年，那么现在在ARTIFACTORY之后可以减少了0.2个，所以能够完全释放一个大部分的人力，它能把时间和精力腾出来去做其他的事情。

另外一个我们的传统的方式的研发，开发完包了之后交给测试和运维的时候，是要推动式的持续交付，首先我要运维确认这个版本对不对，另外测试这个包有没有测，关联的需求对不对，这些问题都是研发和测试都要反复确认的问题，造成大量沟通，并且这些沟通从管理者角度是看不到，管理者角度看到开发测试都很忙，每天忙什么东西？其实有一部分时间都是忙这些事情，这些事情是价值降低的活动，我们就要避免，当然要从组织级别去消灭这件事情。

那么怎么去打通这个制品的传递，首先我们讲了在往深一点去看，为这个团队创建不同成熟度的仓库。Snapshots 就存储开发者的包，然后Stage专门存储待测试的版本，待发布的版本，Release 就是发布完的包，那有的公司还专门有一个投产库，TEAMNMVN的库，那么这个库仓库数的数量其实映射到整个测试环节，是一一对应，有几套测试环境，有几个测试步骤，你就需要几个这样的仓库晋级。

那么仓库搭建好之后我们还要把一个制品传递的一个通道给它梳理好，那么首先开发者在本地拉包的时候是访问虚拟仓库，这个虚拟仓库能够访问到公司的隔离区，隔离区访问到外网，然后把包下载到本地来，那么当然你不是所有的外网源都可以访问，可以访问受信任的源，比如说MAVEN的官方源，DOCKER的官方源，下载到本地之后开发进行构建，并且上传到咱们的LOCAL仓库，LOCAL仓库测试没有问题了，触发流水线，流水线持续集成，然后跑测试，测试没有问题了，然后放到RELEASE仓库，然后咱们管理员运维只来访问RELEASE仓库来进行打包，那这样的话你会发现制品的传递非常的清晰，有一条通道，那解决了统一制品管理问题之后。

第二步要干什么，我们是要记录包的源数据，这个也是咱们在DOCKER标准明确要求，信通院规范里面明确要求，制品要自描述，描述制品相关的生命周期，比如说制品关联的代码溯源，制品能不能进行代码溯源，然后制品能不能关联咱们的测试的结果，我这个包有没有通过测试，然后有没有做过代码检测、性能测试，有了标签之后才能够进行生长环境的部署，所以你在CI/CD整个流动过程中产生这些过程数据都是要汇总到制品包上面去的。

我们可以来看一下实际的案例，这个是需求ID，当你要发一个包的时候，溯源的ID是什么点进去就能看到，避免测错包的问题，因为测试很常见它测试包发现根本没有包含我要测的需求，可以通过这个功能测试团队上来一看关联123，这3个需求正是我要测的，没有问题要测了，如果需求不对，不要浪费我的时间，漏洞扫描通过，这是源数据的功能。

有了功能之后，同样公司还要建立规范，咱们在质量内建的时候提到这个包在持续交付过程当中，怎样通过质量关卡的一个设定，然后怎么去做一个质量关卡的识别，就是通过这样的方式，这些数据是怎么来的，都是通过比如说 Jenkins 在构建的时候把一些测试结果通过API方式洗到这个包上面来，比如说单元测试结果是什么，我的测试覆盖率是多少，所以有了这样的数据汇总，那么拿到这个包可以看到，它的测试结果成熟度是多少，然后在决定这个能不能发布，所以这个信息以前是只有测试团队在各个系统上才能够看见，那么现在打通 CI/CD 信息的屏障，所有人都能够看到，是不是减少了很多沟通成本在里面。

有了这个源数据之后，我们要做制品基于源数据的晋级，所以我们可以看到开发者在部署这个包，这是一个 Docker，每一种语言都按照这种流程进行发布，本地测试没有问题放到生长环境，生长环境没有问题到晋级，晋级就是简单把这个包从一个库拷到另外一个库，然后另外那个库成熟度更高一点，就这么简单。最后进入到生产库一定具备各种测试的源数据，那么对于运维来讲我只关心这个库里面的东西，前面你怎么折腾跟运维没有关系。

有了制品晋级流程看一下怎么在一个生长环境中去做持续交付，那么这个就是更详细的一个版本交付的流程，它和 Jenkins 测试环境变更系统去做关联。大家主要看绿色的制品库这块，我们制品晋级的通道，它在晋级过程当中会通过自动化测试结果回写，结果进行晋级，然后在变更系统里面关联交付单，交付单的编号上传到制品库上，源数据一起交给运维人员，运维人员拿到包之后同样相当于源数据也是一个清单了，它会非常清楚知道这次投产要做什么事情，大家想象如果没有这个清单对于运维来说完全是黑盒的，部署完了之后这个包到底对不对他也不知道，出了问题他要背锅，这是不是很冤。你说这次交了一个包关联了代码版本，分支都不对，给了一个测试环境的分支，给了一个分支的包，如果没有源数据信息直接到生产，那么通过数据去进行安全的交付。

通过源数据在Jenkins里面可以脚本接口找到版本做持续发布，具体的脚本可以通过源数据识别找到复合源数据版本的包进行拉取，所以看到请求拉包不仅拉这个包，还拉源数据，基于源数据的检测，如果通过才能拉到这个包。可以看一下咱们基于容器发布的流程，前面讲的是单服务，怎么实现真正流动式发布，包括 JFrog 自己也有很长的实践，我们用 HELM 来打包发布我们的产品，然后在发布之前修复BUG的时候，我们会有一个K8S 测试环境，能够一键创建一个 namespace 给到开发的，然后每天我们会自动的链条每个团队交付的 release 出来的稳定版本进行一个测试环境的统一搭建，统一测试，这个SIT的链条环境测试通过了，把制品从这个预发仓库晋级到发布仓库，大家看这是两个仓库，这是两条流水线，两个HELM的环境，这两个环境是一模一样的，都是用咱们的HELM去定义的，所以一旦每天都会有Release在这个制品，Release要生产库之后生产流水线Jenkins会拉到每天生产仓库的Release版本，然后用HELM部署到咱们的生产环境去，所以这是多模块的流动式发布的场景。

这样有什么好处，我们开发者在本地，当他想要验证一个BUG的时候，可以直接看下一页，这个是一个实例，当他想要验证一个BUG重建起来成本比较高，比如说搭建8台虚拟机，才能把场景重建出来，那么对于传统的情况如果用了HELM，那你需要半天的时间不一定能够搭建这个环境[01:16:31]，那你需要半天的时间不一定能够搭起这个环境，因为你还要配置，所以用了Helm Chart之后你用一个模版，然后能够分钟级的把这8个容器实力全部跑出来，然后开发自己快速验证修复没有问题了，然后打包 release 一个镜像出来，然后在智能环境进行验证了，就是这样一个流程，所以这就是我们说的流动式持续交付的一个理念，那么这个方案也是大家拿起可以直接用的，Jenkins集成，这是比较成熟的方案包括一些脚本都有现成。

然后ARTIFACTORY能够统一代理所有外网依赖，这个就比较简单了，这个大家都知道，所有开发团队通过ARTIFACTORY下载所有的依赖，所以不需要在分装一个[01:17:38]。

使用 JFrog Xray 进行组件漏洞扫描

最后一个小节，当我们在CI/CD做的事情比较顺畅之后其实还有一个影响我们交付就是安全，

开发者2019年的安全报告，技能处于明显的短板，认为是重灾区，Apache Spring框架都存在高位漏洞。

所以对于大公司来讲会有一个问题某个漏洞爆发了，然后哪些团队正在用，基本上没有办法去排查，然后即使这个漏洞爆发之后也没有办法去组织它去下载，另外这个安全左移是没有办法去做，这是企业安全的挑战。

我们能够带领所有第三方仓库，基本上创建第三方库白名单方式提升到内盒，基于白名单仓库，基于这个漏洞影响范围，比如说操作系统或者 Apache 漏洞包报漏了，有一个高危漏洞，我们工具里面能够快速定位哪些迹象中间漏洞给影响到了，这是实时定位，那么在之前你可能需要一个安全的团队帮你去识别，你要自己去查，那么现在立刻就可以查到，立刻可以让它下线，避免公司的损失。

最后总结一下部署场景，研发可以部署 Artifactory，生长环境部署一个；在隔离区部署一个，这样一站式解决你所有跟制品相关的问题，通过这样的方式能大大提升跟制品相关持续交付的效果，这也是我们通过 5000 家客户的实践。

那么我今天的分享就到这里，然后大家如果对制品管理感兴趣可以扫我的微信，备注一下来意就可以了。

QA：谢谢老师的分享，有一个问题需要您回答一下，如何快速开发测试部署？

王青：我们是这样，刚才其实也提到了，我们在K8S环境里面用到HELM仓库，我们的所有产品线所有的项目其实都是用HELM来管理的发布周期，那如果用 HELM 来做的话，有一个前提写很多可重用的HELM脚本，比如说我们的制品库，你想要部署它的时候，在开发者空间里面给它快速虚拟出来部署的，如果部署3个加数据库可能有6到7个，我们给它虚拟出来，让它自己快速验证它的DOCKER镜像里面这些应用是否正确，如果正确他自己会自动回收它的环境，以同样的方式部署到线上的环节，当然文件不一样，所以大家用容器了，建议大家去用HELM仓库去管理咱们应用，当然HELM官方的子项目，所以它有社区大厂的维护，所以现在也到了3.0，用户体验也比2.0好很多，更加安全，所以大家可以去试用一下。