mod

极客时间专栏/DevOps实战笔记/总结答疑篇/期中总结 | 3个典型问题答疑及如何高效学习.md

@@ -0,0 +1,192 @@
+<audio id="audio" title="期中总结 | 3个典型问题答疑及如何高效学习" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/d5/293f08f27499d3e043b76c3e16b418d5.mp3"></audio>
+
+你好，我是石雪峰。不知不觉中，专栏已经上线快两个月了，整体进度过半。我在专栏写作之初就给自己定下了一个小目标：**认真对待每一条留言**。到现在，单单是回复留言，我就已经写了3万多字了。
+
+其实，对我来说，每一次看留言和回复留言，都是一个不断反思和学习的过程。实际上，很多时候，很多留言和讨论甚至比文章本身都更精彩，也更接地气。
+
+今天是期中总结，我分为两个部分内容来讲：
+
+- 第1部分：我从众多留言中挑选了3个典型问题，进一步展开讲解。
+- 第2部分：我想跟你说说心里话。两个月的高强度写作，也让我从一个讲师的角度，重新审视了“如何高效学习”这件事情，我把这些想法分享给你，希望可以帮助你更好地提升自己。
+
+## 典型问题
+
+首先，我们来看一些典型问题。
+
+### 问题一
+
+> 
+敏捷开发模式没有花费大量时间去研究业务，这会不会出现因为对业务没有分析透，导致方向偏离，甚至系统开发到一半发现总体业务架构不合理，需要返工的情况呢？
+
+
+相信你也知道，实施DevOps有助于产品快速和高质量的交付，那么，我想问的是：快速和高质量的交付，是否就一定意味着业务的成功呢？显然没有这么简单。
+
+实际上，影响业务成功的因素有很多，比如，行业趋势、产品竞争力、用户消费习惯、政策法律法规等等。在这众多因素之中，需求质量的高低，或者说，需求是否靠谱，也很重要。
+
+毕竟，如果交付了一大堆没用的需求，不仅没法提升业务，反而还会浪费大量的时间和精力，错过真正有价值的机会。
+
+我们身处在一个飞速变化的时代，企业对于用户想要什么其实并不清楚。很多需求都是人为拍脑袋拍出来的。在提出一个新需求的时候，需求价值到底有多少呢？这不仅很难预测，而且还很难衡量。
+
+所以，产品人员就倾向于采用“广撒网”的方式，提出一大堆需求，来提升命中的几率。毕竟，如果一次猜不对，打不准，那就多打几次呗。
+
+这么看来，采用敏捷开发方式，还是瀑布开发方式，与需求是否靠谱并没有直接关系。即便是采用瀑布模式，依然也有“大力出悲剧”的案例，比如摩托罗拉的铱星计划。
+
+既然无法事先预测需求是否靠谱，那么要解决这个问题，就需要业务团队和交付团队的通力协作了。
+
+**从业务侧来说，就是要采取精益创业的思想，通过最小可行产品，将需求进行拆解，通过原型产品降低市场的试错成本**。这就引出了我在[“业务敏捷”](https://time.geekbang.org/column/article/155791)这一讲中提到的**影响地图**、**卡诺模型**、**用户故事**等一系列的手段和方法，核心还是采用**持续迭代、小步快跑的方式**来获取市场反馈。正因为如此，更加灵活拥抱变化的敏捷开发模式才被广泛地接受。
+
+说完了业务侧，再来看看交付侧。
+
+一个想法被提出来以后，需要经过软件开发交付过程，才能最终交付到用户手中。那么，就要**用尽一切手段来缩短这条交付链路的时长**。
+
+如果开发的时间成本是一定的，那么剩余的部分，就是DevOps中的各种工程实践试图要去解决的问题。
+
+比如，通过持续集成来降低软件集成中的解决成本，降低软件缺陷在最后一刻被发现的修复成本；通过自动化测试，降低大量手工回归测试用例执行的成本，降低新功能导致已有功能出现回退的修复成本。软件交付过程中的其他部分也大都如此，这也是每个领域都会有自己的实践集合的原因。
+
+反过来看，功能上线之后，依然需要交付侧提取、汇总和及时反馈业务指标，来证明需求的靠谱程度，从而帮助业务侧更加有序地进行决策。对反映不好的功能及时止损，对反映不错的功能加大投入。
+
+这样一来，**业务侧的需求拆解、需求分析减小了需求颗粒度，提升了需求的靠谱度；交付侧的工程实践大大缩短了上线交付周期，提升了质量**。这就帮助业务在不增加成本的前提下，可以验证更多的需求。这个过程的成本越低，频率越高，企业存活下来的几率和整体竞争力也会越高。这也正是DevOps想要解决的核心真问题。
+
+### 问题二
+
+> 
+公司对于配置管理的关注度不是很高，有没有什么好的落地实践方法，来建设完整的配置管理体系呢？
+
+
+在专栏的[第10讲](https://time.geekbang.org/column/article/160477)，我从4个核心原则出发，介绍了配置管理的相关知识，引起了很多同学的共鸣。
+
+的确，作为一个长期被忽视，但是格外重要的实践，配置管理不仅是诸多DevOps工程实践的基础，也是工程能力的集大成者。
+
+正因为如此，**配置管理体系的建设，并不只是做好配置管理就够了。实际上，这还依赖于其他工程实践的共同实施**。
+
+关于配置管理怎么落地，我跟你分享一个案例。
+
+这家公司最早也没有专职的配置管理，软件的集成和发布都是由研发团队自行管理的。推动建立配置管理体系的契机，源于公司决定加快版本发布节奏，从三周一个版本变成两周一个版本。看起来，这只是版本发布周期缩短了一周，但是，就像我在专栏[第4讲](https://time.geekbang.org/column/article/148878)中演示的部署引力图一样，想要达成这个目标，需要方方面面的努力，其中就包括配置管理。
+
+于是，公司决定引入配置管理岗位。初期，他们重点就做两件事：
+
+- 重新定义分支策略，从长分支改为了短分支加特性分支的模式；
+- 管理集成权限，从任何时间都能集成代码，到按照版本周期管控集成。
+
+在这个过程中，配置管理同学梳理了代码仓库的目录结构和存储方式，并基于开发流程建立了在线提测平台，从而实现了研发过程的线上化以及权限管理的自动化。
+
+接下来，配置管理与平台和流程相结合，开发过程开始向前、向后延展。
+
+- **向前**：在需求管理阶段，建立需求和代码的关联规范，严格约束代码提交检查，并且将构建工具和环境配置等纳入统一管控，可追溯历史变更；
+- **向后**：在部署运维阶段，定义版本发布和上线规则，建立单一可信的发布渠道，可统一查询所有正式发布版本的信息，包括版本关联的需求信息、代码信息、测试信息等。
+
+团队在走上有序开发的正轨之后，就针对发现的问题，逐步加强了平台和自动化能力的建设。
+
+- 代码提交失控：做集成线上化，测试验收通过之后，自动合并代码；
+- 环境差异大：通过容器化和服务端配置管理工具，实现统一的初始化；
+- 构建速度慢：通过网络改造和增量编译等，提升构建速度。
+
+这样一来，版本发布这件事情，从原本耗时耗力的操作，最终变成了一键式的操作，团队也达成了预期的双周发版的目标。
+
+在这个案例中，配置管理更多是从流程和平台入手，通过规则制定、权限管控、统一信息源，以及版本控制手段，重塑了整个开发协作的交付过程。
+
+所以，在把握原则的基础上，面对诸多实践，想要确定哪些实践可以解决实际问题，**最好是要从预期结果进行反推**。
+
+如果你不知道该从哪里入手，不妨看看现在的软件交付流程是否是由配置管理来驱动的，是否还有一些数据是失控和混乱的状态，版本的信息是否还无法完整回溯。如果是的话，那么，这些都是大有可为的事情。
+
+总之，**任何一家公司想要落地配置管理，都可以先从标准化到自动化，然后再到数据化和服务化**。这是一条相对通用的路径，也是实施配置管理的总体指南。
+
+### 问题三
+
+> 
+度量指标要如何跟组织和个人关联？这么多指标，到底该如何跟项目关联起来呢？
+
+
+我在[第19讲](https://time.geekbang.org/column/article/169385)中介绍了正向度量的实践，引发了一个小高潮。文章发出后，有不少同学加我好友，并跟我深入沟通和探讨了度量建设的问题。由此可见，当前，企业的研发度量应该是一个大热门。
+
+但是，度量这个事情吧，你越做就越会发现，这是个无底洞。那么，在最最开始，有没有可以用来指导实践的参考步骤呢？当然是有的。我总结了四个步骤：**找抓手、对大数、看差距、分级别。**
+
+**第1步：找抓手。**
+
+对于度量体系建设来说，很多公司其实都大同小异。最开始的时候，核心都是需要有一个抓手来梳理整个研发过程。这个抓手，往往就是需求。因为，**只有需求是贯穿研发交付过程始终的，没有之一**。
+
+当然，你也可以思考一下，除了需求，是否还有其他选项？那么，**围绕需求的核心指标，首先是需要提取的内容**。如果，连一个需求在交付周期内各个阶段的流转时长都没有，那么，这个度量就是不合格的。
+
+**第2步：对大数。**
+
+对大数，也就是说，当度量系统按照指标定义，提取和运算出来指标数据之后，最重要的就是**验证数据的真实有效性，并且让团队认可这个客观数据**。
+
+很多时候，如果公司里面没有一套权威指标，各个部门、系统就都会有自己的度量口径。如果是在没有共识的前提下讨论这个事情，基本也没什么意义。所以，说白了，一定要让团队认可这些大数的合理性。
+
+**第3步：找差距。**
+
+抓手有了，核心大数也有了，大家也都承认这个度量数据的客观有效性了。但是，在这个阶段，肯定有些地方还是明显不合理。这个时候，就需要对这个领域进一步进行拆分。比如，测试周期在大的阶段里只是一个数字，但实际上，这里面包含了N多个过程；比如，功能测试、产品走查、埋点测试等等。
+
+如果没有把表面问题，细分成各个步骤的实际情况，你就很难说清楚，到底是哪个步骤导致的问题。所以，**在达成共识的前提下，识别可改进的内容，这就是一个阶段性的胜利**。
+
+**第4步：分级别。**
+
+**实际上，不是所有指标都可以关联到个人的**。比如，如果要计算个人的需求前置周期，这是不是感觉有点怪呢？同样，应用的上线崩溃率这种指标，也很难关联到一个具体的部门。
+
+所以，**我们需要根据不同的视角和维度划分指标**。比如，可以划分组织级指标、团队级指标和项目级指标。
+
+**划分指标的核心还是由大到小，从指标受众和试图解决的问题出发，进行层层拆解，从而直达问题的根本原因**，比如用户操作原因、数据计算原因、自动化平台原因等等。当然，这是一件非常细致的工作。
+
+我们再来回顾下，我们刚刚深入剖析了3个DevOps的典型问题。
+
+首先，你要非常清楚地知道，DevOps在面对未知需求时的解题方法和解题套路，那就是业务侧尽量拆解分析靠谱需求，交付侧以最快、最低的成本完成交付。它们之间就是一个命运共同体，一荣俱荣，一损俱损。
+
+配置管理作为DevOps的核心基础实践，在实施的过程中，并不只局限在单一领域。实际上，要从研发流程优化的视角出发，驱动标准化、自动化和数据可视化的能力建设。
+
+最后，关于度量指标部分，你要注意的是，**向上，要支撑核心指标；向下，要层层分解，展示真实细节**。
+
+讲解完这3个典型问题之后，接下来进入第2部分，这也是我极力要求增加的部分。其实，我就是想跟你说说心里话。
+
+## 如何高效学习？
+
+跟你一样，我也是极客时间的用户，订阅了很多感兴趣的课程。在学习的过程中，我一直在思考，如何在有限的时间内高效学习。直到我自己成为了课程老师，从用户和老师两个角度思考这个问题，有了一些感悟，想要跟你分享一下。
+
+忙，是现在大多数人的真实生活写照。我们每天从早到晚，忙于工作，忙于开会，忙于刷手机……忙得一塌糊涂。
+
+但是，如果要问，过去的一天，自己都在忙什么，要么是大脑一片空白，要么是碎碎念式的流水账。可见，我们每天忙的很多事情，都没有什么价值。
+
+其实，很多事情，都没有我们想象得那么重要。我们常常把目光聚焦于眼前，眼前的事情就变成了整个世界。但是，如果把时间拉长到一周，甚至一年，你会发现，这些事情，做与不做没有什么分别。
+
+正因为时刻处于忙碌的状态，所以，抽出一整段时间学习，就变成了一件奢侈的事情。但我要祝贺你，因为至少你比大多数人有意识，有危机感，愿意拿出零碎的时间，来充实自己。
+
+既然花了这么难得的时间，你肯定希望能有所收获，无论是在知识上，还是能力上，抑或是见识上，至少不白白浪费这段时间。
+
+那么，我想问的是，你真的有收获吗？
+
+史蒂芬·科维曾经说过，大多数人聆听的目的是为了“怼回去”，而不是为了真正的理解。
+
+> 
+Most of people listen with the intent to reply, but not with the intent to understand.
+
+
+这里面的“怼回去”稍微有点夸张，实际上，我发现，当我在交流的时候，脑海里总是不自觉地想象如何回复对方，而不是专心地听对方讲话，感悟他的意图和情绪。
+
+所以你看，听这种学习方式，总是会受到固有思维模式的影响。也就是说，在很多时候，我们往往会把自己置身于一种评论者的身份。
+
+那么，什么是评论者的身份呢？这就是说，**站在一种置身事外的立场，以一种审视的角度，来看待每一件事情，并试图找到一些问题。当然，这些问题，都是在已有的认知局限中发现的**。
+
+这些反馈，对于知识的生产者而言，其实是一件好事，因为他能够时刻审视自己，反思自己，并从中找到不足之处。
+
+但是，对学习者来说，能不能在学习的过程中，暂时放弃评论者的身份，转而做一个实践者呢？
+
+比如，以极客时间的专栏为例，对于作者提到的内容，你有哪些不同的观点呢？面对同样的问题，你又有哪些更好的手段呢？
+
+其实，每一个作者之所以能成为作者，都有他的独到之处。那么，**能够让他的思想为你所用，让他的知识与你互补，让你自己成为交流的赢家，这才是对得起时间的更好选择**。
+
+最后，以极客时间的专栏为例，我认为：
+
+- 60分的体验，就是可以看完所有的文稿，而不是仅仅听完课程音频；
+- 70分的体验，就是可以仔细学习文稿中的附加资源，比如代码、流程图以及补充的学习信息等。这些都是精选的内容，可以帮助你在15分钟之外，扩充自己的知识面；
+- 80分的体验，就是可以积极参与到专栏的留言和讨论中，甚至可以就自己的问题跟作者深入交流，建立连接；
+- 90分的体验，就是可以结合工作中的实际场景，给出自己的思考和答案，并积累出自己的一整套知识体系，并且，可以反向输出给其他人；
+- 100分的体验，就是持续改进。我想，能够具备这种思想，可能要比100分本身更重要。
+
+那么，你想做到多少分的体验呢？你可以自己想一想。
+
+好了，接下来，我们即将进入“工具实践篇”，希望你可以继续保持学习的热情，坚持下去，期待美好的事情自然发生。
+
+## 思考题
+
+对于前面已经更新的内容，你还有什么疑惑点吗？或者说，你在实践的过程中，有什么问题吗？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。

极客时间专栏/DevOps实战笔记/总结答疑篇/期末总结 | 在云时代，如何选择一款合适的流水线工具？.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="期末总结 | 在云时代，如何选择一款合适的流水线工具？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5f/0f/5f53af4f60aaf9bb462535db0d3f980f.mp3"></audio>
+
+你好，我是石雪峰。今天是期末总结，我们来聊一聊，在云时代，如何选择一款合适的流水线工具。
+
+在过去的几年里，我一直专注于软件持续交付的工程实践领域。我发现，越来越多的公司（无论规模大小）开始重视软件持续交付能力的建设了，基本上每家公司都有自己的流水线平台。
+
+以前提到CI/CD工具，基本上就默认是Jenkins，也没什么其他太好的选项。但是最近两年，随着云容器技术的快速发展，在CI/CD流水线领域，新工具和解决方案出现了爆发式的增长。比如不甘寂寞的GitLab CI、轻量级的容器化解决方案Drone。最近一段时间，GitHub的Actions也火了一把。可见，作为软件交付主路径上的核心工具，**流水线**是每一家企业都不愿意错过的领域。
+
+对于行业发展来说，这当然是好事情。老牌工具Jenkins自己都开始反省：“在云容器时代，是不是过于保守？十几年的老架构是否已经难以支撑云时代的快速发展了？”于是他们就另辟蹊径，孵化出了Jenkins X项目。
+
+但是，对于用户来说，选择工具时就很为难：“这些工具看起来大同小异，要解决的也是类似的问题，到底应该选择哪个呢？”
+
+今天，我就来给你梳理一下流行的CI/CD工具，并给你提供一些选择建议。我挑选了5个工具，分为3组介绍，分别是Jenkins系的Jenkins和Jenkins X、版本控制系统系的GitLab CI和GitHub Actions，以及新兴的、正在快速普及的云原生解决方案Drone。我会从5个方面入手，对它们进行对比和介绍，包括工具的易用性、流水线设计、插件生态、扩展性配置以及适用场景。
+
+## Jenkins/Jenkins X
+
+关于Jenkins，我想已经不需要做太多介绍了。在过去的15年里面，Jenkins一直都在为无数的软件开发者默默服务。从一组数字中，我们就能看出来它的影响力：官方能统计到的集群数有26万多个、插件将近1700个、执行的任务数超过3000万次，这还不包括大量公司自建、本地电脑运行的节点信息。另外，一年两次的Jenkins全球大会往往能够吸引上千人参与，这对于国外的技术大会来说，已经是超大规模的盛会了。
+
+当然，Jenkins的优缺点也很明显。
+
+- 优点：普及率高，搞过开发的基本应该都接触过；插件生态成熟且丰富，可以适用于任何场景。
+- 缺点：软件架构和UI设计风格有些过时，配置操作比较复杂；插件的安全性、通用性方面也存在很多问题，最重要的是，在云容器领域，多少有些格格不入。
+
+我重点说说Jenkins X。很多人都不清楚Jenkins和Jenkins X是什么关系，这就好比刚开始我们很难说清楚Java和JavaScript的关系一样。实际上，JavaScript除了名字上带有“Java”字眼，蹭了个热度之外，本质上它们之间并没有什么关系。而对于Jenkins和Jenkins X来说，虽然并不能说二者一点关系没有，但其实它们面对的场景和要解决的问题是不同的。所以，并不能说Jenkins X就是下一代Jenkins，或者是Jenkins迟早会迁移到Jenkins X上面。
+
+Jenkins X最开始的确是作为Jenkins的子项目存在的，但是发展到现在，它已经有了独立的品牌和Logo，并且和Jenkins一起作为CDF（持续交付基金会）的初始项目。Jenkins X想要解决的核心问题是**Kubernetes上的原生CI/CD解决方案**。所以，Jenkins X和Kubernetes是强绑定的关系，**它致力于通过一系列的自动化工具和最佳实践，来降低云原生环境下的研发配置和使用CI/CD的成本，并尽可能地做成开箱即用的状态**。
+
+而Jenkins更像一个百宝箱，你可以通过插件扩展来解决各种各样的问题，并没有一定之规。
+
+我给你举个例子，来形象地对比一下Jenkins和Jenkins X这两个项目。
+
+Jenkins就好比你在开车，你知道目的地，但是走哪条路，开多快，中间要不要休息一下，什么时候加油，这些都是你自己来决定的。当然，灵活性带来的就是多变性，你并不知道是不是下一秒就封路了或者是汽车突然坏了。
+
+而Jenkins X更像是一辆高速列车，你只要上对了车，列车会把你安全、快速地送往目的地，而你并不需要关心这个车是怎么设计的，时速应该是多少，甚至你在哪里能够下车，它都规定好了。
+
+Jenkins X项目中内建了大量的开源工具和解决方案，可以说是开源工具的理想国和试验田，核心目的就是为了简单、快速、开箱即用。比如对Tekton的集成，就被视为对Jenkins自身的颠覆，因为这彻底改变了Jenkins流水线调度机制。因为在Jenkins X看来，Jenkins只不过是Jenkins X中的一个应用，是一个黑盒子，编排通过Tekton来实现，换句话说，即便你想用其他应用来取代Jenkins，也不是不可能的。
+
+值得注意的是，Jenkins X中有很多约束，比如你必须使用GitOps的方案来完成应用的晋级和部署，没有其他的选择。**如果你没有使用Helm管理应用，也不想使用GitOps，那就现阶段来说，Jenkins X对你就不是一个可选项**。
+
+我们来总结一下Jenkins X项目：
+
+- **工具的易用性**：采用了开箱即用的设计，提供大量的模板来降低新应用上手CI/CD的成本。虽然安装复杂，但是目前已经提供了JX Boot工具，通过初始化向导帮你完成环境搭建。而且，随着云服务商的引入，环境方面应该都是可以默认提供的，就像你不需要操心如何搭建Kubernetes一样，因为会有人以服务的形式把Jenkins X提供出来。
+- **流水线设计**：Tekton取代了Jenkins，成为了流水线的默认引擎，作为Kubernetes的原生解决方案，这也是未来的发展趋势。在编排方面，它采用了yaml方式，继承了原有Jenkinsfile的语法特征，并对Tekton的资源进行隐藏和抽象，通过描述式的语言，以代码化的方式实现，可以说是当前的通用解决方案。不过，它目前并没有提供可视化的编排界面。
+- **插件生态**：继承了Jenkins丰富的插件生态，以及庞大的开发者社区。
+- **扩展性配置**：采用容器化的解决方案，对于Tekton来说更是如此。每个步骤都在容器中完成，可扩展性非常强。
+- **适用场景**：我认为，Jenkins X项目现在还处于快速开发的阶段，适用于原型产品验证。对于那些没有固有模式，想要沿用Jenkins X的设计流程的项目来说，可以尝试使用。不过由于云服务商的接入度不足，目前应该还存在很多挑战，你可以保持学习和跟进。毕竟，这个项目中的很多工具和设计思路都是非常有价值的。
+
+<img src="https://static001.geekbang.org/resource/image/79/4f/79f9d1264ef1881af524afd9c9cc0c4f.png" alt="">
+
+## GitLab CI/GitHub Actions
+
+除了Jenkins，国内使用比较多的应该当属GitLab CI了。前些年也有过社区的讨论，到底应该使用GitLab CI，还是Jenkins？很显然，这样的讨论并不能达成共识，毕竟“萝卜白菜，各有所爱”。而GitHub Actions的推出，也是看中了流水线编排领域的“蛋糕”。曾经，GitHub和TravisCI是珠联璧合，可以说是“开源双碧”。GitHub也一再强调，**自己只想把代码托管服务做到极致，其他领域都交给合作伙伴完成**。但是今天的Package功能和Actions功能都体现出了GitHub自建生态的野心。
+
+其实，这两个产品有很多相似之处，因为它们都是依托于一个成熟的代码托管平台衍生出来的原生流水线功能。
+
+对于软件开发而言，最重要的无疑就是源代码。之前，我有个同事就说过，只要掌握了源代码，你就可以为所欲为了。比如，基于代码拓展代码评审工具、内建各类静态动态代码检查功能、增加包管理和依赖管理工具等，这些是代码编译之前和编译之后的必备功能。增加内建的持续集成功能，也有助于在代码评审的时候做到机器辅助。
+
+当这些功能都集成到代码托管系统中时，你就会发现，它不再是一个简单的版本控制系统了，而是一整套DevOps平台。它们的设计理念是，一个平台解决所有DevOps的工具问题。这一点在GitLab的路线图规划中，也体现得淋漓尽致，GitLab对主流工具都进行了对比，并提供了一个工具的全景图。可以说在行业对标方面，GitLab是做到极致了。你可以参考一下下面这张全景图和他们自己写的对比[文章](https://about.gitlab.com/blog/2018/09/03/how-gitlab-ci-compares-with-the-three-variants-of-jenkins/)。
+
+<img src="https://static001.geekbang.org/resource/image/58/bc/58c8f850329b90378e6f9ee3a8eb15bc.png" alt="">
+
+> 
+图片来源：[https://about.gitlab.com/devops-tools/](https://about.gitlab.com/devops-tools/)
+
+
+回到流水线方面，GitLab CI和GitHub Actions都和版本控制系统进行了深度集成。我们还是从五个方面来整体看一下。
+
+**1.工具的易用性**
+
+- **易于上手**：由于是内建功能，GitLab CI/GitHub Actions使用起来都非常简单，你并不需要单独构建和维护一个独立的CI服务器来实现这个功能。
+- **原生体验**：由于是原生功能，所以无论是在流水线状态展示方面，还是在代码评审流程的集成方面，它们都做到了原生化的体验，显示的信息和丰富程度是外部独立的CI工具所无法比拟的。
+- **一体化协同平台**：工具链繁多、集成配置复杂、信息分散，都是DevOps工具方面的痛点问题。而一体化的研发协同平台的价值就在于能够集中解决这些问题。开发者不需要在各种工具系统中跳来跳去，可以在一个地方解决所有问题，在一个地方看到所有有用的数据。
+- **在线文档**：GitLab的文档和示例都非常丰富，GitHub就相对薄弱一些，不过两者的文档基本都够用。
+
+**2.流水线设计**
+
+- **流水线描述**：GitLab CI和GitHub Actions都采用了yaml形式的流水线过程描述文件，二者的语法规则虽然不同，但基本上大同小异。但相对来说，GitHub的语法规则更加符合当前Kubernetes的资源描述风格。关于这两个产品的语法风格，你可以看下这两份资料：[GitHub Actions](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)，[GitLab CI](https://docs.gitlab.com/ee/ci/yaml/)
+- **流水线编辑**：两个产品都支持在线编辑流水线文件，GitHub在这方面更加人性化一些。当你打开Actions的时候，系统会给你推荐一些模板，你可以直接选择生成Actions配置。如果想自己编辑Actions文件的话，系统的右侧也提供了很多示例代码片段，让你可以通过简单的复制、粘贴完成这项工作。另外，GitHub新版本提供了在线的可视化编辑器，毕竟GitHub Actions是全新设计的，集合了各方面的优势。
+
+**3.插件生态**
+
+- **GitLab生态**：作为一个开源软件，GitLab的优势也恰恰在于开源，官方对于社区PR和feature的响应也是非常及时的。但是，由于GitLab是基于Ruby语言、Rails框架开发的，这个语言就成了比较大的瓶颈，毕竟，熟练掌握Ruby语言的国内开发者相对还是比较少的，所以GitLab的插件生态并没有做起来。
+- **GitHub生态**：GitHub有建设Marketplace的长期经验，再加上开源贡献者众多，所以，在短短一年左右的时间里，他们已经积累了1700多个Actions组件，可以帮助你快速地搭建自己的流水线。从扩展性和生态丰富性方面来说，GitHub更胜一筹。
+- **使用成本**：必须要强调的是，GitHub是商业软件，虽然对待开源项目采用免费策略，**但是如果企业级使用的话，成本也是必须要考虑的因素之一**，而自建GitLab如果采用社区版本，就没有这么多限制了，这也是优势之一。
+
+**4.扩展性配置**
+
+它们都支持多种环境类型。GitLab很早就提供了对容器和Kubernetes的支持，GitHub在这方面自然也不会落后，官方提供了Linux、Windows和Mac环境的支持，你也可以自建节点并注册到GitHub中。不过必须强调一点，GitHub如果是非企业版本的话，是不支持私有化部署的，这也就意味着，如果你想把企业内部的资源注册到GitHub上，那么就意味着这些资源必须对外可见。
+
+**5.适用场景**
+
+由于国内GitLab自建服务的普及，如果你对CI的功能要求没有那么高，那么GitLab CI就足够了。但是，在功能广度方面，由于缺少庞大的插件生态，很多功能还是更多地依赖于你自己实现，所以，如果软件交付流程非常复杂，依赖于多种环境，GitLab CI就不是那么适用了。
+
+而GitHub在企业中的使用场景就更加有限了，一方面是成本问题，另一方面，SaaS化服务依赖于内部开放性。所以，如果是开源项目，或者创业项目不希望自己维护一套很重的研发基础设施，那么我建议你考虑使用GitHub的方案。
+
+在最新发布的2019年Forrester的趋势报告中，GitLab和Jenkisn都入选了云原生CI工具的榜单，并且处于行业领先地位，你可以看一下报告的图片。虽然图中没有写明Jenkins，但是其背后的CloudBees公司，以及目前在云原生项目Jenkins X中有深度合作的Google公司都处于领先地位，由此可以看出，各大公司都已经开始在云原生领域布局了。
+
+<img src="https://static001.geekbang.org/resource/image/16/6f/16ce91c79b1de82c33119c3e8964ee6f.png" alt="">
+
+## Drone
+
+这也是一个近来冉冉升起的CI工具领域的新星。在咱们专栏的留言中，有很多同学提到过这个工具，可见，**好工具是会自己说话的**。
+
+Drone主打的就是云原生CI，整体设计非常轻量级，即便没有什么经验，一两天也能快速上手搭建。在我看来，Jenkins X虽然也是主打云原生，但由于引入了大量组件和流程约束，整体还是略显笨重一些。相反，Drone的实现非常优雅，无论是流水线的语法，还是环境的扩展性方面，都让人不由得赞叹。
+
+作为一个开源软件，Drone使用Go语言实现。在我看来，Go就是为云原生而存在的，无论是Docker、Kubernetes，还是我参与的Jenkins X项目，都是通过Go语言来实现的。所以，这个项目对于内部开发团队快速提升Go语言的DevOps平台建设能力，也是一个很好的参考学习案例。
+
+对于Drone平台，我目前也在学习和探索阶段，我从下面这几个方面谈谈我个人的看法。
+
+**1.工具的易用性**
+
+Drone的搭建非常简单，你可以采用自建服务的形式，也可以使用SaaS服务。UI风格设计体现了恰到好处的理念，整体非常清爽，同时也能跟其他工具（如GitHub）进行集成。
+
+**2.流水线设计**
+
+作为云原生的解决方案，流水线同样采用yaml形式、具备描述式表达和流水线即代码的功能。虽然没有过于复杂的语法，但是Drone的流水线语法风格是我个人最喜欢的，它的结构非常清晰。
+
+**3.插件生态**
+
+Drone也提供了插件机制，而且官方还提供了对主流版本控制系统和云服务商的集成支持。虽然数量远远比不上Jenkins生态，但是你能想到的基本都有了。比如常见的Artifactory、SonarQube、Ansible等工具，甚至还包含了对微信、钉钉这类国内流行的通讯软件的集成。由于它的开放特性，未来它也会提供更多的插件。
+
+**4.扩展性配置**
+
+对于Drone来说，最大的特征就是容器优先。上面提到的这些工具虽然都支持容器，但是并没有把容器作为默认支持的第一选项。而在Drone中，容器则是标配，这也是典型的云原生CI工具的特征：**一切都在容器中运行**。也正因为如此，非容器化开发部署的项目如果采用Drone就不太合适了。另外，除了容器方式之外，Drone也支持本地执行，这为一些特殊的场景提供了可能性（比如绑定设备的自动化测试等）。
+
+**5.适用场景**
+
+我认为，**Drone在云原生CI/CD方面的设计代表了未来的趋势**。对于基于容器开发交付的产品来说，如果你在寻找一个对应的云原生解决方案，那么我推荐你用Drone。它也比较适合于中小型团队、初创公司想要快速受益于CI/CD，又不想投入太多精力的场景。同时，作为一款Go语言开发的开源软件，随着业务扩展，你大可以自建插件，满足差异化的需求。
+
+## 总结
+
+最后，为了方便你理解和进行对比学习，我把这五个云原生流水线工具的特征汇总了图片里。
+
+<img src="https://static001.geekbang.org/resource/image/e8/b3/e8a17696ad63fe145a6d258069ab2bb3.jpg" alt="">
+
+到此为止，这几款主流的流水线工具，我就介绍完了。在文章的最后，我还想再补充两点：
+
+1. **工具并非决定性的因素**，不要轻易陷入“工具决定论”的思想之中，就好比真正的编程高手可能都不需要IDE，选择好的工具，并不代表就有好的结果。
+1. 工具是“存在即合理”的，它们都有各自擅长的领域，**没有绝对意义上的最好，只有最适合的场景**。另外，即便是同一个工具，在不同的人手中发挥的作用也不一样，选择自己最熟悉的工具，一般都不会有错。比如你要问我选择什么工具的话，我肯定推荐Jenkins。但这并不是因为Jenkins完美无缺，而仅仅是因为我用得顺手而已。
+
+## 思考题
+
+对于Drone这款工具在生产环境的应用，你有哪些实际的经验，又踩过哪些“坑”呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。