本文编辑：白凡
今天我分享的主题是《基于容器和微服务的持续交付流水线》，单从标题来看，汇聚了今年来的几大热点词汇，像容器、微服务和持续交付流水线，很多人也在关注这些技术领域如何能够有机的整合起来，为业务价值带来贡献，这也是我们今天要探讨的内容。
今天的分享有三个方面：
-
DevOps和持续交付
-
构建持续交付流水线
- 开源流水线演示分析
1. DevOps和持续交付
这张图是去年在上海的Jenkins用户大会上，Jenkins的创始人KK在他的主题演讲中分享的，意思是说软件正在吃掉整个世界。
无独有偶，之前微软公司的创始人盖茨提到微软公司的宗旨，也是说软件代表了世界的将来。对于这些行业领袖的观点，不知道大家是怎么理解的。
1.1 为什么需要关注DevOps
现在越来越多的企业不再将IT视为成本中心，而是作为企业的核心竞争力，为什么IT变得如此重要，我们可以举个简单的例子，以往大家办理银行业务都是去网点或营业厅，排号等待柜台的一对一服务。
而现在，大多数情况下我们都是通过手机完成的，银行的形象不再局限于窗明几净的营业大厅，而是手机设备的方寸屏幕之间。
由此可见IT软件不仅仅是维护企业内部的正常信息运转，而是跟客户直接打交道，我们所看到的软件界面就是企业的形象。从这一点来看，软件是无处不在的，所以我们有幸在这个时代里从事这份职业是值得庆幸的。
正因为业务越来越复杂，软件交付也越发成为企业价值交付的瓶颈，于是DevOps应运而生，从Google趋势来看，DevOps诞生将近十年，尤其最近五年，DevOps的走势是陡然上升的。
在过去两年间，我们也充分感受到国内谈论DevOps的人越来越多，以至于对所有人来说，在DevOps领域最新的事情，就是DevOps已经不再新了。
2.1.2 DevOps的价值所在
越来越多企业已经开始认识到DevOps的价值，所以开始实施DevOps，建立DevOps转型落地团队。
右边的数据来源于去年的DevOps状态报告，DevOps团队比例从14年的16%提升到了27%。
而从左边的数据可以看到，50%的企业正在引入并实施DevOps，超过80%的企业已经有相关计划，所以如果现在还不做的话，你就是那1%。
1.3 DevOps和持续交付
问题是实施DevOps的路径是非常曲折的，从国外很多知名公司的经验来看，整个过程漫长要花费几年的时间，那么究竟从哪里入手DevOps呢？我认为核心在于持续交付驱动DevOps落地。
DevOps和持续交付是相生相长的，持续交付关注代码提交到交付用户价值的完整过程，打通了从研发到用户的价值交付链条。
可以看到整个环节中，最左边是研发和运维共同驱动流水线，经过层层的质量验证最终交付给用户手中，这个过程中涉及到多条流水线，每条流水线的关注领域和价值也各不相同。
所以如何设计一条高效的流水线对很多人来说是一件非常困难的事情。
随着云原生应用的兴起，现在整个工具体系成一种爆发的趋势，随着各领域工具的不断成熟，其中一些开始脱颖而出。
比如在容器编排领域Kubernetes已经成为不二选择，另外过去一年中的行业并购也比比皆是，比如CloudBees收购CodeShip，红帽收购CoreOS，这些都让工具系统的竞争逐渐明朗，占主导地位的企业不断扩大自己的优势。
，为什么在流水线领域没有主导的解决方案呢？是不是大家可以用同样的解决方案解决所有软件价值交付的问题呢？回答显然是否定的。
其背后的原因在于设计持续交付流水线的时候涉及的要素非常复杂，在各个项目里展现出来的形式都是千差万别的。
这涉及到业务形态、交付流程、组织架构、系统工具、基础设施等等，共同构成了持续交付的流水线，导致每个人的流水线都是不同的，所以我们无法简单的模仿，而需要探寻设计一条好的流水线背后的理念、步骤和实践要素。
2. 构建持续交付流水线
在设计流水线的时候，我们经常听到一个名词就是价值流分析（VSM），这套理论方法源于传统制作业，体现了精益的核心思想：发现浪费，消除浪费。
其实无论企业目前的价值交付过程是否高效，流水线都是客观存在的，我们要做的就是首先梳理和识别现有的价值交付流程。
2.1 梳理自己的流水线
为什么流水线一直存在还要梳理呢？原因在于我们之前的视角更多的局限于各自领域，比如开发只关心开发的事情，最多看看上下游，而缺乏全局意识。
2.1.1 看清全局
所以，我们实施DevOps最重要的第一步是看清全局，VSM所带来的价值也正是如此。
2.1.2 识别浪费
第二，VSM能识别浪费，对开发来说，只有在梳理VSM的时候才发现由于自己嫌麻烦而不做代码单元测试或者代码评审，这对后端的测试和运维带来多大的工作量，同样对运维而言，他们也才发现是因为研发不了解基础设施架构，所以才给出如此复杂的上线部署脚本。
在这个过程中，大家才能互相了解彼此在做什么事情。所以我们梳理出企业价值交付的链条，可以清楚地看到从开发到上线的过程是如何运转的，在每个环节有不同的角色承担不同的职能，在每个环节里通过快速的反馈机制建立反馈环。
当我们梳理清楚整个企业价值交付的流程之后，要做的事情其实没有任何变化，接下来的工作就是自动化。
这个图我个人非常喜欢，我们原本单个存在的研发人员，通过流水线可以把他们连通起来。通过自动化赋有原有的人员更高的效率和能力。它不仅提供单点的效率，更重要的是提升整体的效率。
2.1.3全流程工具链接入
在我们的演示项目中选择的绝大部分工具都是开源工具，用这些方案是想尝试证明一件事情，在不做很大规模的投入的时候，流水线能不能建立起来？我之前跟部分企业交流的时候，他们投入了上百万的资金用于建立协同研发平台，这个成本并不是每个公司都能接受的。
我们把开源工具集成到流水线里，大家发现流水线并不是全能的工具，它只是一个入口，利用了开源工具和已有的工具解决方案去解决问题。流水线应该是一个平台，不需要颠覆现有的企业里存在的系统，这是我们设计流水线时非常重要的思路。
2.1.4 内建质量和度量持续改进
通过内建质量，在各个阶段给出快速反馈，主动避免缺陷流入下游，这是DevOps种职责共享和Ownership的体现。
度量驱动持续改进，这是非常重要的，只有通过度量收集数据，才能把问题清晰地展现出来，用事实和数据证明自己的观点。
这是CapitalOne开源的可视化度量工具平台，提供丰富的接口，可以跟现有的工具做集成，通过可视化的大屏幕能看到代码提交的效率、质量，推荐大家可以回去试用。
始终记得度量是持续改进的基础，而持续改进是DevOps能够成功落地的根本要素。在丰田即便从没有人谈论DevOps，但是由于他们的持续改进做的非常好，深入每个员工的行为之中，所以才造就了制造业的典范。
刚才简单解释了流水线的特点，我们总结一下：
-
第一，打通端到端。如果流水线在设计的时候只是停留在开发环节，这些流水线都不完整。设计流水线的时候一定要从代码提交一直到线上，整个环节都是价值流动的环节，流水线都要覆盖到这些环节里。
-
第二，自动化。
-
第三，做工具整合。流水线不要尝试取代所有东西，而是作为平台整合能力。
-
第四，建立反馈机制，可以快速地改进。
- 第五，持续改进。
这是我们开源流水线项目的示意图，这其中有些阶段是串行的，有些阶段是并行的，有些是手动，有些是自动的，怎么把这个东西梳理出来？这就是我提到的梳理价值流图，只有这样才知道代码上线需要经历哪些团队、环节，到底是自动还是手动。
只有把价值流完全梳理出来后，才能定义出清晰的流水线，才能在每个环节内做自动化，同时把数据做统一的度量和展示，这是非常重要的。
3. 开源流水线演示分析
3.1 流水线交付案例
我们的流水线基于一个开源的微服务电商项目，大家可以看到在这个项目中的前后端模块涉及多种技术栈，而且每个服务都有自己的数据库，消息队列等，对于真实项目可能不会这么复杂，但是之所以选择这个项目，主要还是为了验证持续交付流水线能不能跑通。
这个架构图在去年Jenkins用户大会上第一次发布，列出了流水线设计的思路，我强调几点。中间的Jenkins，它是驱动流水线的原动力，在Jenkins下面有不同级别的流水线。
我反复强调流水线应该是端到端的，但并没有说是一条流水线覆盖端到端。这里非常重要的特性是流水线的分级，对于不同的级别流水线所承载的使命是不一样的。对于提交阶段流水线，它负责的就是快速给研发以反馈，验证阶段是验证流水线的代码提交质量和可靠性，完成更多的测试环节，部署流水线就是完成线上的部署。
右边可以看到，Jenkins上插接了很多开源的工具，包括商用工具，这些工具提供了我们看到每个环节里的能力。
最左边是需求管理，这是价值交付的源头，我们目前采用的JIRA，因为JIRA是当前主流的需求管理平台。基于JIRA，我们设计了用户故事地图和基于看板的研发协作模型。同时，基于Gitlab管理源代码。采用了短生命周期特性分支的研发模式，来驱动开发的持续集成和代码Review环节。
下面这张图更清晰地梳理出研发工作的流程，研发人员下载代码，本地开发测试完成后提交到主线上，触发提交阶段流水线。
这里会用到Docker仓库和Helm，使用K8S做应用管理大多会跟Helm打交道。他们用于制品管理，存储流水线过程中的产物。
在流水线不同的阶段，会把新的功能和软件部署到不同的集群里，这就利用到K8S的环境隔离特性。通过不同环境的层层验证、质量的把控，最终流入到线上生产环节。
给大家做一个简单的演示，因为我们是一个开源项目，所以设计的思路、源代码都会开源出来，提供给大家，大家可以基于这些东西实现自己的想法。
3.2 需求管理
基于用户故事地图的需求管理，可以清晰的展示需求分布，进行需求拆解和编排，调整需求优先级，驱动敏捷开发迭代。
基于看板的方式进行开发协同管理。我们可以看到看板里定义了很多阶段，通过看板可以非常清晰地展示出项目的状态，并且把精益思想和配置管理实践整合进来，比如限制在制品数量，明确的规则，需求和代码的集成关联，状态自动流转等，大家可以自己定制。
3.3 代码提交阶段
代码提交到特性分支之后，自动会触发提交阶段流水线，主要用于基本的编译和测试，代码规约检查等，给与研发快速反馈，每个环节都可以通过Jenkins的界面获取日志和反馈信息。如果这个环节出现问题会在第一时间反馈出来，帮助研发及时修复，避免代码合入后阻塞主线分支。
在提交阶段验收完成后，我们会把特性合并到主线分支并触发集成阶段流水线。这个流水线会包含更多的步骤，如等待部署、等待测试的环节。在流水线里存在人工把控的能力，可以完成手工测试和不同环境的部署。
环境的部署是自动完成的，当我们做到持续交付，特性的集成非常频繁，测试很难对每个提交都做完整的验证。对测试来说，可以根据工作的计划，通过一键部署后进行测试。在整个过程里，流水线跟JIRA产生联动，即随着流水线的流动，JIRA下面的需求状态可以自动流转，不需要手工，保证的信息状态的一致性，通过这些方法尽量减少人为的工作。
3.4 部署阶段
对于部署阶段流水线来说，很多公司还没有做到自动化部署，基本都是调用已有的运维部署平台实现，在我们的演示中直接使用Jenkins，这个步骤相对简单，主要涉及到灰度发布的一些实现。
以上是一个快速的演示，接下来我们来聊聊其他的内容。
随着云原生应用时代的来临，技术变革带来了深远的影响，当我们开始基于容器和微服务开发的时候，开发是非常痛苦的，因为他不仅要完成编码工作，还要懂流水线，还要写测试用例，有的时候还要写Dockerfile，这对研发的知识体系带来了极大的挑战。
对于云原生应用时代有一个非常复杂的体系，即DCCM体系。D指DevOps，C指持续交付，C指容器，M是微服务。
有人问我，我不做容器，不做微服务，能不能做DevOps？显然是可以的。因为很多非常传统的公司也在践行DevOps，比如做POS机和ATM的公司，它是非常传统，也在做DevOps。
可是为什么每次谈DevOps都会看到容器和微服务如影随形？这主要是因为它更符合云原生应用时代应用开发的特点，这也是为什么它们能促进彼此的发展。
3.5 流水线的下一站
流水线的下一站到底是什么？这是我年初去比利时访问时收货的一个想法，即流水线的下一站就是CDaaS，流水线即服务，听起来很高端，那具体要怎么做呢？
3.6 良好持续交付平台的能力
一个良好的持续交付平台应该具备什么能力？
第一，自服务能力。
我们之前做过一个工作流的平台，类似于工单，它只是一个工作流，仍然需要后端人员的处理和反馈，这显然不是我们希望的场景。因此，对于持续交付平台来说，第一重要的就是自服务能力。
自服务能力是判断持续交付平台到底是不是完善的一个核心要素，即你可以依赖于我的平台，但是你不能依赖于我这个人。如果提供了一个持续交付平台，还依赖于人去做很多工作，这就没有做到自服务。
第二，独立组合。
持续交付平台里很多功能可以独立使用，比如自动化测试，他是一个能力的集合，而能力之间没有强烈的耦合和依赖，是可以独立组合的。
第三，弱约束。
很多公司去设计持续交付平台的时候是强约束的，强约束即上线交付必须经过构建、测试、部署三个步骤，缺一不可，听起来很美，但实际上不同的项目类型，这样的流程和开发模式并不是满足实际需求。
在这一点来说，我们的系统不要设计强约束的研发流程系统，而是提供一种能力，让大家可以自定义流程。
第四，快速上手。
对于内部产品来说，我们总觉得够用就行，而现在越来越强调产品化思路。之前有人说，我费了好大劲做的平台别人不用怎么办？只能说说你这个平台做得不够好。
如果你提供一个平台可以解决问题，他还不想用，肯定有很多原因在里面，其中之一就是系统不能满足他的需求，用起来比不用还麻烦，那么这个系统设计之初就没有以用户思路来做事。
第五，内建实践。
通过平台内建很多实践，比如快速反馈。
之前有人说，我建立流水线了，要紧急上线的话就走一个领导特批流程，或者快速上线流程，这就是设计流水线的时候还要给你一个口，领导一审批就绕过所有测试直达上线，这就违背了很多最佳实践。你用流水线的前提是梳理整个价值流，而且大家认可这个最佳实践，这是非常重要的。
第六，插件市场。
现在很多公司平台多了一个入口，叫Marketplace，像Github就有Marketplace，为什么会有插件市场？它就是提供一种可扩展能力，并且成为了一个生态系统。
举个例子，我们之前要做针对JS的自动化测试，而流水线不具备这样的能力，但是某个做JS的团队自己有一个工具，我们可以把他作为一个插件集成到系统里，它就成为了系统的贡献者，而不只是一个用户。
研发跟我们的关系从以前我提供服务，他来使用的关系，变成大家一起提供服务的关系。当持续交付平台做到足够成熟的时候，要考虑如何设计插件市场的能力。
第七，原生安全和实时更新，这是比较好理解的。对很多公司来说，安全是第一红线，如果没有通过流水线去约束上线流程，怎么保证经过安全扫描呢？只有通过流水线，才能把安全机制和能力固定化到流水线里。
3.6 DevOps工程师的标准
什么样的工程师才能开发出这样的系统？答案是最好的工程师，如果公司开始关注工程效率，而又不舍得投入最好的人才，那么实际就不是真正想做这个事情。对于DevOps的工程师需要什么能力？按照我个人理解要具备三个条件。
-
第一，编码能力。
-
第二，重构业务整个流程，DevOps工程师要关注业务，要有产品化思维，要做价值流的梳理，当然这很难。如果不理解业务交付流程，你设计出来的东西就是自动化部署平台，不是DevOps平台，不是持续交付平台。
- 第三，软实力，就是沟通和协作的能力，很多系统不是自己在用，而是团队用。如果在座各位想招聘DevOps工程师可以从这三点考察。
说了这么多，有没有东西可以做到自服务呢？是有的，就是叫Jenkins X，它是基于云原生时代的持续交付解决方案，感兴趣可以参考我的线上分享。
4. 总结
最后，卖一个情怀。
这个图大家有看过吗？我之前做线上分享也提到过这个故事，在乔布斯生前的访谈中，他提到过一件有趣的事情，叫做“人脑自行车”。
故事是这样的，乔布斯在小的时候看《美国科学画报》，里面提到有科学家研究世界上动物的运动效率，即达到相同的移动距离所消耗的能量是多少。
这个平台通过各方面的统计，发现地球上运动效率最高的生物是秃鹫，而人排名在倒数几名。但是，这些科学家又做了一个特别有趣的调研，人骑自行车的运动效率跟秃鹫进行对比，结果发现人骑自行车的效率远远超过了秃鹫。
我们要善于去发明一些工具，人脑自行车是通过计算机大大提高了人脑运算速度。我们做DevOps转型，做持续交付的时候，也需要这辆自行车，而这辆自行车就是持续交付流水线，谨以此跟大家共勉，希望看到更多流水线的优秀实践，谢谢大家。