在 8 月 31 日举行的北美开源峰会上,Linux 的创造者 Torvalds 在与 VMware 的首席开源官 Dirk Hohndel 的谈话中分享了他对 Linux 未来的看法。他称如果他被巴士撞了他不担心内核会受到冲击。虽然这个假设不太吉利,但却很有道理,为什么呢?
工作流程比代码更重要
“我真正担心的是补丁的流程,工作流程比代码更重要,”Torvalds 说。“如果你有正确的工作流程,代码就会自行解决,如果出现错误,我们知道如何处理。”
他承认他现在不清楚内核中的每一行代码,但这并非是一件坏事。Torvalds 说,内核的庞大规模导致了它日益复杂化,而开源模式是内核成功的核心。因为在复杂的世界里,应对复杂性的唯一方法是公开交流想法。你不能在一个封闭的环境中管理复杂性。
自 1992 年起 Linus 开始采纳其他开发人员的补丁,如今,Linus 拥有一个实力超群的内核维护小组,Linux 系统的协助模式是 Linus 负责总体的协调和沟通,他会对接十余名核心贡献者,每个人都有自己负责的具体领域和项目内容,每次有新的开发任务时 Linus 会将它分配给对应的人;而这十余位核心贡献者又有各自的熟知并信赖的高手小团队。Linus 只需知道将任务交给他自己团队中十余名成员哪个人即可。
Dirk Hohndel 曾经问 Linus,这样的开发模式是否可持续?Linus 笑着回答如果当前团队中有 程序员 变老变胖(感觉像在说自己哈哈)不想继续做下去的话也没有问题,因为会有新的程序员补充进来。Dirk 又追问 Linus 道,在内核不断提升迭代的过程中,是不是你具有着绝对的决定权?Linus 回答到“不是的”,他发自内心地鼓励大家按照自己的需求建立 fork,如果最终这样的想法有良好的结果做证明,其精华部分就会被吸收到 Linux 内核项目中。Dirk 对此总结,当今的分支发展再吸收代码的模式其实反映的就是 Linus 本人或其团队的决定性。
不难看出,Linus 等技术大神对于软件开发的流程都非常看重。一个设计完备、良好运转的软件开发流程,对于提升软件工程的效率,解决突发问题都大有裨益,那么问题来了,怎么做呢?我们看一下 Facebook 的经验案例。
Facebook 是怎么做开发与部署的?
Facebook 是世界上最大的社交网站,早在 2017 年,其月活就超过了 20 亿,是微信的两倍还多。支持这样一个站点的运行,还要不断发布新的功能,Facebook 的工程师是如何做到这一切的?
Facebook 的工程师们不会像传统软件行业那样使用瀑布模型进行开发,他们不断地开发新的功能,并迅速上线,让用户能够访问到这些新功能,这就是大家口中经常提到的持续部署(continuous deployment)。在他们看来,Facebook 的开发永远没有到头的那一天,代码库在不停地增长着,代码随时间呈现超线性增长的趋势。
在 Facebook,所有前端工程师都工作在同一个稳定的分支上,这也能加快开发速度,因为省去了繁琐的分支合并过程。在日常开发中,每个人都用 git 在本地进行开发,当代码就绪之后,就会将它推送到 SVN 上(之所以是 SVN,这是出于历史原因),这样就很自然地区分开了开发中的代码和可以上线的代码。
但是为了保证网站的稳定运行,并非是工程师将代码推送到 SVN 上,认为可以上线,代码就能发布上线的。Facebook 采用了一种兼顾了速度与稳定性的做法——将每日发布与每周发布结合到一起。所有的代码变动默认是每周发布,每次发布会包含相对比较多的变更,在每周日的下午,代码会被发布工程师推送到 SVN 上,随后会进行大量的自动测试,其中包含很多针对正确性和性能的回归测试,这个版本会成为 Facebook 员工内部使用的默认版本,正式的发布通常被安排在周二下午。
发布工程师会为每个工程师的历史表现打分,内部称为“Push Karma”,比如那些代码经常出问题的人,分数就会相对较低,他们的代码自然也会受到更多的“关照”。这样做的目的是控制发布的风险,而非对某人做出评判,因此这个分数是保密的。除此之外,越是大的变更,或者在 Code Review 时讨论越是多的代码,也是风险较高的地方,同样会受到更多的“关照”。
在被纳入发布之前,代码已经经过了开发者的单元测试和 Code Review,在 Facebook,Code Review 是非常重要的事情,他们使用名为 Phabricator 的 工具 进行 Code Reivew,该工具是和代码版本管理整合在一起的。
在大量的自动化测试之外,每位员工在内部使用 Facebook 时也相当于进行了高密度的测试,每位员工都能报告自己发现的问题,写代码的人多了,代码增长的快了,相对而言,对代码进行测试的人也多了。
在性能方面,Facebook 使用 Perflab 对新老代码的性能进行对比,如果新的代码性能不理想,并且开发工程师无法及时修复,那么相关代码就会从本次发布中剔除出去,待问题修复后再进行发布。每个小的性能问题都是不容忽视的,因为小问题会很快累积起来,变成影响容量和性能的大问题,Perflab 能通过图表的形式直观地展现系统的性能。
Facebook 每周的发布是分阶段进行的,首先是 H1,即部署到仅有内部访问的服务器上,进行最后的测试,很多公司也称其为“预发布”;随后是 H2,部署到几千台服务器上,开放给一小部分用户;如果 H2 阶段没有发现问题,则进入 H3,部署到全部服务器上。
如果在这个过程中发现问题,工程师会立即进行修复,随后重新开始分阶段的部署。当然,也可以选择回滚代码,有两种回滚方式——常见的是回滚某个变更及其依赖的文件,另一种则是回滚整个二进制包。
这个“准持续(quasi-continuous)发布周期”的最大优点在于:它迫使我们开发下一代工具、自动化和流程,以使公司能够扩大规模。
在发布时,与变更相关的开发者必须在线,发布工程师会通过 IRC 机器人进行确认,如果人不在,那么他的变更会被回滚。这样保证了问题能够在上线之初就被快速发现并修复,当然,想在这么大的一个系统里及时发现一些问题有时也是很困难的,所以 Facebook 会结合内部工具 Claspin 和外部的信息源(比如 Twitter)持续地监控系统的健康状态。
通过 Gatekeeper 系统,工程师们可以方便地控制多少用户能够访问特定的新功能,筛选的条件可以是地区,也可以是年龄,在遇到问题时也能迅速关闭某个功能的入口。在 Gatekeeper 的帮助下,工程师们能方便地进行 A/B 测试,藉此迅速收集用户的真实体验,对产品做出调整。不要忘了,在 Facebook,是工程师来选择自己做什么的,那么工程师们肯定是选择把东西做出来,看看用户的反应,而不是坐在会议室里和一堆人开会去猜测用户想要什么。
现在,Facebook 有数千名名开发工程师,但却没有独立的测试工程师。每位工程师都可以看到全部的代码,并且能提交补丁,或者提交详细的问题描述。工程师们需要自己编写详尽的单元测试,他们的代码还要通过所有的回归测试,并能支持后续的各种运维工作。
除了要对自己的代码负责,他们还要面对各种巨大的挑战,往往要针对多种解决方案进行大量试验。比如,当时为了解决 PHP 的性能问题,有 3 个不同的方案同时在进行开发,当某个方案的负责人发现另一个方案更好时,他们就会停下来;最后 HipHop 胜出了,但另两组人的精力也没白费,他们提供了重要的备份能力。
Linux公社的RSS地址: https://www.linuxidc.com/rssFeed.aspx
本文永久更新链接地址: https://www.linuxidc.com/Linux/2018-09/153863.htm
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 内核必须懂(六): 使用kgdb调试内核
- Linux内核如何替换内核函数并调用原始函数
- Linux内核工程师是怎么步入内核殿堂的?
- Linux内核工程师是怎么步入内核殿堂的?
- 面试官:说说操作系统微内核和 Dubbo 微内核?
- Linux 内核的核心维护者表示鲜有手机供应商更新内核
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
The Algorithmic Beauty of Plants
Przemyslaw Prusinkiewicz、Aristid Lindenmayer / Springer / 1996-4-18 / USD 99.00
Now available in an affordable softcover edition, this classic in Springer's acclaimed Virtual Laboratory series is the first comprehensive account of the computer simulation of plant development. 150......一起来看看 《The Algorithmic Beauty of Plants》 这本书的介绍吧!