基于容器和微服务的端到端持续交付流水线

白凡

分享：石雪峰
编辑：白凡

今天主题是基于容器和微服务的持续交付流水线，这个主题还是蛮高的，既有容器，也有微服务，也有持续交付流水线。

今天的分享有三个方面：

• DevOps和持续交付
• 构建持续交付流水线
• 开源流水线演示分析

1. DevOps和持续交付

这张图是去年KK的一张PPT，是说软件正在吃掉整个世界，不知道大家怎么理解这个事情。

1.1 为什么需要关注DevOps

现在越来越多IT不再是成本中心，而是企业的核心竞争力，从这一点来看，软件是无处不在的，所以我们有幸在这个时代里从事这份职业是庆幸的。举个简单的例子，为什么IT越来越重要？

大家之前去银行办业务是去网点或营业厅，等待柜台提供一对一服务。而现在，通过手机进行，我们提供的软件不仅仅是维护企业内部的正常信息运转，而是跟客户直接打交道。你看到的软件界面就是企业的形象。

正因为这样的背景越来越复杂，所以DevOps应运而生。DevOps诞生将近十年了。这是Google趋势，最近五年，DevOps的走势是陡然上升。在过去两年，国内谈DevOps的人越来越多，对所有人来说，DevOps不再是全新的事物。在DevOps里最新的事情是DevOps不再新了。

1.2 DevOps的价值所在

现在还谈DevOps是因为越来越多企业认识到DevOps的价值，所以开始落地实施DevOps，建立DevOps的团队。右边的图是DevOps的报告里的数据，DevOps团队从9%提升到27%，现在50%的企业正在引入并实施DevOps。已经有80%的企业正在着手实施DevOps，如果你再不做的话，你就是那1%。

1.3 DevOps和持续交付

DevOps转型后是这样的，DevOps的路径是非常曲折的，怎么做DevOps呢？是持续交付驱动DevOps落地。

为什么说持续交付？DevOps和持续交付是相生相长的，DevOps打通了从研发到用户的链条，可以看到整个环节。最左边是研发和运维，共同驱动流水线，来为用户提供价值。其核心是涉及到不同的流水线，之前跟很多人交流的时候，落地或设计流水线是非常困难的事情。

这张图放在这里是想说明一点，现在的工具非常复杂，但是呈现一种趋势，是什么呢？现在，很多工具越发成熟，而且企业间的并购展现出各个领域的软件慢慢成为主导地位。

但是，有一个问题，为什么我们在流水线的领域没有主导的解决方案呢？我们从来没有看到，是不是大家可以用同样的解决方案解决企业价值交付的事情？这样的原因是什么呢？在于我们在设计持续交付流水线的时候涉及的要素非常复杂，在各个项目里展现出来的形式都是千差万别的。这涉及到业务形态、交付流程、组织架构、系统工具、基础设施等等，构成了持续交付的流水线。我们设计流水线是快速落地持续交付非常重要的因素。

2. 构建持续交付流水线

我们经常听到一个名词就是价值流分析（VSM），它是源于很多制造业的思想，主要目的是发现浪费，消除浪费。
这幅图是在企业里真正实施价值流的结果。现在你们的企业里到底有没有流水线？一定是有的，不管过程多么低效，还是有流水线的。

2.1 梳理自己的流水线

为什么流水线一直存在还要梳理呢？之前软件开发是关注自己的各自领域，开发关注开发，最多是跟上下游打交道。

2.1.1 看清全局

所以，我们要做DevOps第一步最重要的是看清全局。VSM第一点是能看清全局。

2.1.2 识别浪费

第二，能识别浪费，而且对很多研发人员在梳理VSM的时候，才知道在这个环节因为嫌麻烦而导致后端的事故有多么严重。对运维来说，是研发人员不了解基础设施，才给出这么复杂的脚本、流程。

在这个过程中，大家才能互相了解彼此在做什么事情。所以我们梳理出一个东西，即企业价值交付的链条。我们可以清楚地看到从开发一直到上线交付价值的过程是如何运转的，在每个环节有不同的角色承担不同的职能，在每个环节里通过快速的反馈机制建立反馈环。

当我们梳理清楚我们整个企业价值交付的流程之后，要做的事情没有任何变化，还是在做自动化。这个图我个人非常喜欢，我们原本单个存在的研发人员，通过流水线可以把他们连通起来。通过自动化的能力赋有原有的人员这样的能力。它不仅提供单点的效率，更重要的是提升整体的效率。

2.1.3全流程工具链接入

大部分工具都是开源工具，要用这些方案是尝试证明一件事情，在不做很大范围的投入时，流水线能不能建立起来？我跟企业交流的时候，他们投入了上百万的资金建立系统，这个成本并不是每个公司都能接受的。我们把开源工具集成到流水线里。在流水线里，大家发现流水线并不是全能的工具，它只是一个入口，利用了开源工具和已有的工具解决方案去解决问题。流水线应该是一个平台，不应该颠覆现有的企业里存在的系统平台，它应该是一个入口汇聚的点，所以我们设计流水线时非常重要的思路。

2.1.4 内建质量和度量持续改进

通过内建质量，在各个渠道给出快速反馈，避免缺陷流入下游。

度量驱动持续改进，这是非常重要的，我们明确地度量，收集数据，才能把它清晰地展现出来。这是前些日子非常火的开源，我简单玩了一下，它提供非常好的接口，跟现有的工具做集成，能展现成这样。通过可视化的大屏幕能看到代码提交的效率、质量。只有看到里面的问题，才有可能优化持续交付的过程。所以，度量是持续交付里非常重要的环节。

刚才简单解释了流水线的特点，我们总结一下：

• 第一，打通端到端。之前流水线在设计的时候只是停留在设计、开发环节，这些流水线都不完整。设计流水线的时候一定要从代码提交一直到线上，整个环节都是价值流动的环节，流水线都要覆盖到这些环节里。
• 第二，自动化。
• 第三，做工具整合。流水线不要尝试取代所有东西，而是作为平台整合很多能力。
• 第四，建立反馈机制，可以快速地改进。
• 第五，持续改进。

这就诞生出这个流程图（见PPT），它就是我们设计验收阶段流水线的过程。有些阶段是串行，有些阶段是并行，有些是手动，有些是自动的，怎么把这个东西梳理出来？这就是我提到的我们要梳理价值流图，我们就知道代码想上线需要经历哪些团队、环节，到底是自动还是手动。只有把价值流完全梳理出来后，才能定义出清晰的流水线，才能在每个环节内做自动化，同时把数据做统一的度量和展示，这是非常重要的。

3. 开源流水线演示分析

3.1 流水线交付案例

我们做微服务项目是典型的电商项目，大家可以看到有前端、后端，而且每个服务都有自己的数据和解决方案，这是典型的案例。可能公司不会这么做，大型项目是这样，但小型项目不用这么复杂。我们选择微服务项目是验证这个项目在我们持续交付流水线能不能跑通。

这个图在去年Jenkins用户大会上第一次发布出来，列出了流水线设计的思路，我强调几点。看中间的Jenkins，它是驱动流水线的原动力，在Jenkins下面有不同级别的流水线。流水线应该是端到端的，但它不是一条流水线覆盖端到端。流水线非常重要的特性是流水线的分级，对于不同的分级的流水线所承载的使命是不一样的。对于提交阶段流水线，它负责的就是快速给研发以反馈，验证阶段是验证流水线的代码提交质量和可靠性，完成更多的测试环节，部署流水线就是完成线上的部署。

右边可以看到，Jenkins上插接了很多开源的工具，包括商用工具，这些工具提供了我们看到每个环节里的能力。最左边是需求方，对于需求来说，是价值交付的最源头，是把需求纳入到流水线里。我们目前引用了JIRA，因为JIRA是比较主要的平台。基于JIRA平台，我们设计了用户故事地图和基于看板的研发协作模型。同时，基于Gitlab去承载原代码管理，去管理我们的配置管理。采用了短分支的研发模式，去完成整个代码的提交。

下面这张图更清晰地梳理出研发工作的流程，在这个流程里，当我下载一个代码之后，我可以在本地做测试，测试完成后提交到主线上。这会应用到Docker的仓库和Helm，基于K8S做应用管理会跟Helm打交道。这些都是外部的，它会存储过程中的产物。在不同的阶段，它会把新上的功能和软件部署到不同的集群里，这就利用到K8S的环境隔离特性。通过不同环境的层层验证、质量的把控，最终流入到线上生产环节，这就是整个持续反馈的实践。

给大家做一个简单的演示，因为我们的项目是要做开源，所以设计的思路、源代码都会在五六月份开源出来，提供给大家，大家可以基于这些东西实现自己的想法。

3.2 需求管理

基于用户故事地图的需求管理，整个用户故事地图在特性上的分布我们可以看到，这里面会调整需求的优先级，从而做敏捷的开发。

这是开发做开发交互的时候，基于看板的方式完成开发的过程。我们可以看到看板里定义了很多阶段，不同的研发阶段。通过这样的看板可以完成研发，它可以非常清晰地展示出项目的状态，而且可以把很多思路整合到看板上来。这是原生JIRA提供的一些功能，大家可以自己去定制。

3.3 代码提交阶段

提交阶段的流水线就是把代码提交到特性分支之后，它会触发自动化的提交阶段的流水线。这个流水线是引用了Jenkins，并没有使用Gitlab流水线的能力，而是在Jenkins里实现。当完成代码提交之后，自动会触发流水线，每个环节都可以通过Jenkins的界面获取日志和反馈信息。如果是错误的话，也会给出一些反馈。

在提交阶段，验收完成后，我们会把特性合并到主线里，接受request之后，会触发集成阶段流水线，这个流水线是刚才看到的截图。这个流水线刚才是停在等待部署、等待测试的环节，在流水线里存在人工把控的能力，可以完成手工测试和不同环境的部署。环境的部署是自动完成的，持续交付的时候，发布的版本会非常多，测试很难对每个提交都做完整的验证。对测试来说，可以根据工作的计划，按期地完成环境的部署，通过一键部署后可以在线上进行测试。在整个过程里，它跟JIRA产生联动，即随着流水线的流动，JIRA下面的这些需求状态可以跟随流水线自动移动，不需要手工。这也是通过JIRA和Jenkins的集成自动实现的。所以，我们通过这些方法尽量减少人为的工作，这就是我们简单的演示。

3.4 部署阶段

对于部署阶段流水线来说，很多公司还没有做到自动化部署，这是通过手工部署完成的，这应该是非常简单。

在云原生应用时代，很多东西跟以前不一样了，再基于容器和微服务开发的时候，开发是非常苦的，研发人员要懂流水线，还要写测试用例，研发是非常辛苦的状态。对于云原生应用时代有一个非常复杂的体系，即DCCM体系。D指DevOps，C指持续交付，C指容器，M是微服务。

有人问我，我不做容器，不做微服务，能不能做DevOps？显然是可以的。因为很多公司在做POS机的升级，它是非常传统，也在做DevOps。为什么每次谈DevOps都看到容器和微服务？因为它更符合云原生应用时代应用开发的特点，这也是为什么它们促进彼此的发展。

3.5 流水线的下一站

流水线的下一站到底是什么？这是我年初去比利时参观时得到的思路，流水线的下一站就是CDaaS，流水线即服务，我们下一步就是做流水线即服务，听起来很高端，那怎么做呢？

3.6 良好持续交付平台的能力

一个良好的持续交付平台应该具备什么能力？
第一，自服务能力。我们之前做过一个工作流的平台，类似于工单，它只是一个工作流，显然不是我们想做到的场景。因此，对于持续交付平台来说，第一就是自服务能力。之前顾老师也提到这一点，自服务能力是判断持续交付平台到底是不是做完善的一个方面，即你可以依赖于我这个平台，但是你不能依赖于我这个人。如果提供了一个持续交付平台，还依赖于人去做很多工作，这就没有做到自服务。
第二，独立组合。持续交付平台里很多功能可以独立用，可以用自动化测试，这是可以独立组合的。
第三，弱约束。很多公司去设计持续交付平台的时候是强约束的，强约束即上线交付必须经过构建、测试、部署，听起来很美，但实际上不同的项目类型，这样的流程和开发模式并不是满足强约束的。在这一点来说，我们的系统不要设计强约束的研发流程系统，而是提供一种能力，让大家可以自动化自定义一些流程。
第四，快速上手。应用性来说，对于做内部产品来说，够用就行，现在来说，越来越做产品化的思路。之前有人说，我做的平台别人不用怎么办？只能说说你这个平台做得不够好。如果你提供一个平台可以解决问题，他还不想用，肯定有很多原因在里面，其中之一就是系统做得不够满足他的需求。
第五，内建实践。通过平台内建很多实践，比如快速反馈。之前有人说，我建立流水线了，要紧急上线的话就走一个领导特批流程，或者快速上线流程，这就是设计流水线的时候还要给你一个口，领导一审批就绕过所有测试直达上线，这就违背了很多最佳实践。你用流水线的前提是梳理整个价值流，而且大家认可这个最佳实践，这是非常重要的。
第六，插件市场。现在很多公司平台多了一个入口，叫Marketplace，像Github就有Marketplace，为什么会有插件市场？它就是提供了一些能力，它也是组成流水线的步骤。举个例子，我们之前要做针对JS测试，之前的流水线不具备这样的能力，但是之前做JS的团队自己有一个工具，就是把能力作为一个插件集成到系统里，它就成为了系统的贡献者，而不只是一个用户。它跟我们的关系从以前我提供服务，他来使用的关系，变成大家一起提供服务的关系。当持续交付平台做到足够成熟的时候，要考虑如何设计插件市场的能力。
第七，原生安全和实时更新，这是比较好理解的。对很多公司来说，安全是第一红线，如果没有通过流水线去约束上线流程，怎么保证经过安全扫描呢？只有通过流水线，才能把安全机制和能力固定化到流水线里。

3.6 DevOps工程师的标准

核心的一点就是自服务，谁能做这个事情？只有最好的工程师才能做。我发现，什么样的工程师才能开发出这样的系统？就是最好的工程师开发出这些系统。DevOps的工程师需要什么能力？简单来说，我个人理解，你做一个DevOps工程师要具备三个条件。

• 第一，脚本和Coding能力。
• 第二，重构整个流程，开始关注业务，运维不只是关注运维，要关注上下游，要做价值流的梳理，当然这很难。如果不理解业务交付流程，你设计出来的东西就是自动化部署平台，不是DevOps平台，不是持续交付平台。
• 第三，软实力，就是沟通和协作的能力，做出很多系统不是自己在用，而是团队用。如果在座各位想招聘DevOps工程师可以从这三点考察。

说了这么多，有没有东西可以做到自服务呢？是有的，就是叫Jenkins X，它是基于云原生时代的解决方案，能实现很多功能。

4. 总结

最后，卖一个情怀。

这个图大家有看过吗？我之前做线上分享也说过这个图，这就是乔布斯生前的访谈，他提到一个故事，这个故事叫“人脑自行车”。乔布斯在小的时候看了《美国科学画报》，里面提到很多学者研究世界上动物的运动效率，即达到运动效率所消耗的能量是多少。这个平台通过各方面的统计，发现地球上运动效率最高的生物是秃鹫，而人排名在倒数几名。但是，它又做了一个特别有趣的调研，人骑自行车的运动效率跟秃鹫进行对比，人骑自行车中消耗的能效比远远超过秃鹫。

这就是我们要善于去发明一些工具，人脑自行车是通过计算机大大提高了人脑运算速度。我们做DevOps转型，做持续交付的时候，也需要这辆自行车，这辆自行车就是持续交付流水线。