Bestony 发布的文章

软件产业的发展非一朝一夕而来。在如今的信息时代,虽然中国的软件产业也取得了不菲的成就,但是从全球范围来看,尚有薄弱之处,这其中尤以基础设施软件为短板。开源软件和开源文化滥觞以来,一方面加速了中国的信息技术产业的发展,缩短了中国和世界领先水平的差距,但是另外一方面,商业的成功也让不少肯埋头于投入大、见效慢、技术难度高的基础设施层面的软件工程和软件理论方面的机构、企业和个人越来越少。

而最近发布的十四五规划,“开源”被首次列入国家规划纲要,数字经济、自主创新得到进一步强调。这对于中国计算产业来说,是机遇,也是挑战。

在挑战面前,才知道谁才是那个更靠谱的人,国内在自主创新方面取得卓越建树的企业并不算太多,大多也是人们耳熟能详的企业,而真正在基础软件领域深耕的企业,更是寥寥。 这其中,华为算是值得一书的一家。这背后,华为每年招募大量的高端人才,则是投入基础设施软件的重兵;除了人才以外,华为丰富的行业经验也让华为更有可能成为做好基础软件创新的企业。这些投入,也正是华为敢于投入精力在基础计算领域的底气。能在面临挑战前做好准备,就能在面对挑战之时,游刃有余。

不仅如此,华为为了让整个基础计算领域蓬勃发展,更是提出了「开源、开放、使能」的口号,来推进整个行业的进步。

开源、开放、使能

在刚刚结束的中国软件产业年会上,华为公司副总裁、计算产品线总裁邓泰华发表了“繁荣软件产业生态,推动数字经济高质量发展”的主题演讲,向广大的软件行业从业者,介绍了华为过去数年的在计算领域进行基础软件开发经验。

整个演讲,一言以概之,便是“三个开源、三个开放、三个使能”,这背后正是华为计算战略在软件产业的落地。

三个开源,打下软件基础

三个开源是指华为在操作系统、企业级数据库和 AI计算框架等三个领域开放的三款产品 —— openEuler、openGauss和 MindSpore。

虽然过去几十年来,基础设施软件从封闭的企业开发方式逐渐演变成了如今的开源、开放方式,但是,我们可以看到,一些重要的基础设施软件,比如 Windows、Oracle 数据库等依旧采用闭源专有的开发和商业模式。随着开源之风东渐,在基础设施领域采用开源方式成为了一种领先的生产力方式,成为了弯道超车的重要动力。长期深耕企业级软件领域的华为,前瞻性地选择了以开源的方式来重兵压上基础软件战线。以开源的方式和企业庞大的资金和人力,推进社区开发者和企业参与到基础软件的研发,打造从底到顶的全产业链软件生态。

以操作系统 openEuler 为例,自2019年3月31日 openEuler 开源以来,社区已有 60 多家企业、机构和组织,3000 多位贡献者,成立了 80 多个 SIG,已有 8 家合作伙伴推出基于 openEuler 的商业发行版,在金融、政府、运营商和电力等各行业得到了广泛商用。在去年,openEuler 社区理事会正式成立、技术委员会升级;今年,又新成立了用户委员会和品牌宣传委员会,社区治理逐步完善,走向“共建、共享、共治”。

借助于开源,openEuler 获得了骄人的成绩。而开源的力量,也同样表现在了开源数据库 openGauss 以及全场景AI计算框架MindSpore 上。目前,已有6家 openGauss 伙伴企业推出基于 openGauss 的商业发行版,超过 16 家企业和机构加入 openGauss 社区,共同打造“高性能、高可靠、高安全”的数据库内核版本。MindSpore 则已经拥有超过 17 万的开发者和超过 22 万的下载量。

这些成绩,不仅仅是软件本身的优秀,更是开源战略所带来的新气象。这些数据,让人很难想象是一年来取得的成就,不过,如果考虑到华为大量的资源、资金、技术、研发等投入,也就不足为奇了。

三个开放,加速软件研发

除了构建一个好的社区,华为还通过开放通用计算鲲鹏应用使能套件 BoostKit、人工智能昇腾应用使能套件 MindX,以及面向开发者开放支持全研发作业流程的完整工具链来实现让开发者可以以更低的成本来完成更高效的软件开发。

鲲鹏应用使能套件 BoostKit 中集成的大量开源组件和加速库,将过去需要通过不断积累才能获得的宝贵的架构经验和最佳实践,得以提供给开发者,帮助开发者用更简单的方式从传统架构迁移至鲲鹏架构。

而昇腾应用使能套件 MindX 则更是提供了大量的人工智能场景所需的模型、行业 SDK 等,其中不仅自带了质检、目标分类、目标检测等 20 多种行业场景,对于开发者来说,可以通过简单的调用 SDK ,实现更加丰富能力的调用。

这样,过去实现成本十分高的研发流程,可以在这两个套件之上更加简单快捷的完成开发,实属难得。而且,鲲鹏和昇腾全栈的开放,也让开发者们可以针对架构进行优化,从而让应用获得一个更好的性能,为后续的体验优化提供燃料。

三个使能,推进产业变革

计算产品中的基础设施类软件从来不是一个简单的问题,往往包含着上游、下游和周边的生态,想要推动一个基础软件的普及,需要长期付出大量的时间和精力来执行相关的工作。而华为在这件事情中,也投入了大量的时间、精力、资金和人力成本,使能上下游,构建整个产品的生态。

一方面,华为积极参与业界主流开源社区,在各个主流开源社区中已经实现 80% 的场景原生支持鲲鹏架构,这使得软件开发企业开箱即用即可完成软件的开发。避免重复造轮子,或开发的功能对特定的架构有需求,有效降低了企业参与的成本。

另一方面,华为还积极地使能软件合作伙伴,为合作伙伴提供了工具、社区、区域资源等多方面支持。不仅是提供软件产品和研发平台,更是帮助合作伙伴取得商业层面的成功。

此外,华为还和教育部联合启动了 “智能基座” 产教融合协同育人基地,目前覆盖超过 70 所高校,并将在未来的五年里,逐步覆盖超过 2700 所高校、高职、高专院校。华为通过在人才培养方面的大量投入来推动产业人才进步和发展,也为中国软件产业的可持续发展打了一剂强心剂。

过去的中国软件产业企业不愿做、不敢做、不想做基础软件,而华为所提供的这些资源、资料、人才以及商业机会,让中国软件产业企业开始试着走上基础软件研发的这条路。也正是华为所付出的这些资源,可以让产业界的众多企业参与到基础软件的研发过程中,共同研发、共同奉献,最终促进中国基础软件领域的蓬勃发展。

不仅如此,通过机制创新的方式,华为还为后续的企业探寻出了一条可行的基础软件发展的道路,让广大生态内的企业可以看到,基础软件并非不能做。过去的企业内部闭源开发已经跟不上时代的发展,成本高昂,而以开源的方式来构建基础软件生态,可以让企业以更低的成本,来研发出好用、能用、易用的基础软件。

无论最终华为的基础软件能取得什么成就,它所走出的这条机制创新的路,都将造福后续的软件研发企业。目前,鲲鹏、昇腾开发者已经超过 50 万,软件合作伙伴超过 2000 家,4500 个行业主流应用完成解决方案认证。这些数字每一天、每一周都在快速增加。

众智合力,走过“无人区”

鲲鹏、昇腾是全栈开放形态,特别是在当前世界大变局的形式下,华为在走一条走“无人”走过的路。从通用计算、AI 计算这两个领域以开放、开源的方式同时发力,华为更是一位领先探索者。

华为通过鲲鹏众智计划和昇腾众智计划,让社区和企业的开发者参与到整个软件生态的进步当中。通过这两个众智计划面向企业、高校、科研院所发起邀请,以项目合作的方式基于鲲鹏、昇腾基础软硬件平台开发加速库、工具插件、算子、网络模型及行业参考设计等,共同完成项目。一方面,可以让高校的学子得到锻炼,另一方面,也建立起了高校、企业、研究所之间的良好合作关系和合作的可能,促进产学研融合共进。

其中,昇腾众智活动启动以来,已有浙江大学、上海交通大学、西安交通大学、中国科学院等超过 40 所高校和科研机构参与。这些高校的参与,为整个行业的发展提供了新血液和新动力,让行业得以进步和升华。而对于每一个参与在众智计划中的个人而言,能够以一个不那么痛苦的方式参与到中国的计算产业变更之中,毫无疑问是一种人生使命的升华。

无论是开源,还是开放,抑或是使能,看起来是不同的方向,但回归到最底层的问题的时候,这三者都解决了一个问题 —— 华为要积极通过和开源社区的合作和开发者的合作、和全球的软件行业从业者合作,共同打造一个良好的企业生态。而这些,正印证了邓泰华在中国软件产业年会上说的那句 ——

最强的智是众智,最大的力是合力。

NESHouse 作为一个黑客松项目,相比于其他正式运行的项目,可能生命周期更短,也不会走入正式运营的阶段。不过,在我个人看来,这个项目的选型、设计等,还是有一些有意思的点,值得和大家分享。

1、 黑客松,要的就是快!

这几天前几篇文章发出去后,不断有一些开发者留言评论:这个项目使用的都是别人的服务,你的价值是什么?

NESHouse 作为一个黑客松项目,目的是在有限的时间内,从 0 到 1 将需求实现,在这个过程中,开发者需要去仔细评估自己所拥有的资源和要达成的目标,让资源和目标匹配,才能很好的完成自己的开发工作,达成自己本次黑客松的目标。

作为一个 Go 后端开发者,在这个项目中,我使用的是 LeanCloud 提供的云服务,而不是使用 gin 自己写一个 http 服务器,似乎不合常理,没有使用自己最熟悉的技术方案。但如果将资源和需求结合起来看,就会发现这个选择是很正常的。gin 固然熟悉,但我不熟悉的是前端,如果我将一部分时间安排在了后端的研发上,必然挤压我在前端开发的时间。

所以在 NEShouse 项目中,我选择了我比较熟悉,且开发时间周期最短的 Serverless 云服务 —— LeanClod 来完成我的后端工作量,这样我可以几乎不用在后端上花费时间和精力来完成工作。在音频服务上选择使用声网,而不是自己实现一套,原因也一致,我的预期是在 72 小时内完成这个项目的研发,而不是自己打造一套完整的实时音频系统。所以必然会选择更加好用,更加现成的解决方案,来简化我自己的工作。

此外,在这个项目中,有一个比较适合进行工作量评估的事情,便是我在项目中使用到了 LeanCloud 的 LiveQuery 的能力。LiveQuery 提供了实时数据同步的能力,使用 WebSocket 也可以实现相同的功能,不过,如何能又好又快,同时在 WebSocket 服务器上完成各种鉴权和扩展能力,是一个麻烦的事情。你可以用这个非常简单的功能,来评估假设你自己来完成所有的功能所需要耗费的时间。这样就可以理解为什么在这个项目中,我选择 LeanCloud 来完成工作。

2、浏览器兼容,你是真的坑!

在 NESHouse 的开发中,其实并没有花费太多的时间,倒是中间因为我回老家,花了不少时间在路上。实际上,在整个项目中,最为费心的,是各种浏览器之间的兼容问题。

基于浏览器的 NESHouse 和其他基于系统原生 API 的音频应用相比,一个很大的问题在于浏览器在处理音频设备上的不同。NESHouse 使用的音频接口是基于浏览器封装后一层的 API,而这个 API 处于考虑保护用户的考虑,在某些特定的场景下,会要求你先产生一些操作才能触发音频播放,所以针对不同的浏览器,你需要编写不同的适配代码,这些代码最终就会让你的代码变得又臭又长,存在大量的冗余代码。

比如说,在微信浏览器中,默认情况下你是无法听到 WebRTC 传回的音频的,需要用户在页面上进行点击,才能进行播放。

NESHouse 在实现这部分的逻辑时,采用的是判断如果用户使用的是微信浏览器,则会显示一个用户授权页面,让用户主动去点击,来完成音频播放的能力。

如果你希望以其他的方式来解决这个问题,那也可以参考 Agora 文档中的相关说明,来实现这部分能力:https://docs.agora.io/cn/Voice/autoplay_policy_web?platform=Web

3、Alpine.js,真香

作为一个后端开发者,对于前端的几大框架,也仅仅局限在可以用,可以写出我想要的功能的应用。但在具体的实现的时候,由于一些原因,我没有使用 Vue/React/Angular 之类的应用,再加上希望在黑客松中使用一些新的技术,于是我使用了 Alpine.js。

什么是 Alpine.js?Alpine.js 是一个在基础的 DOM 上实现了类似 Vue/React 的双向绑定的一个框架,使用 Alpine.js 和 Vue/React 的一个很大的不同点就在于,他可以让你在现有的 HTML 中非常轻松的实现双向绑定,而不需要重写整个代码。

举个例子来说,假设你想要在 Vue/React 中实现双向绑定,你需要将你的代码放在模板中或者转换为 JSX 来获取相应的双向绑定的能力。但在 Alpine.js 中,你需要做的仅仅是在你需要绑定的地方加入 x-model=xxx 来实现绑定,十分简单。

不仅如此,Alpine 也实现了大部分 Vue/React 之类应用实现的功能,比如 x-forx-onx-if 等常用的命令,在实际写逻辑的时候,我大量的应用了这些逻辑来完成我自己的工作,十分方便。

在 NESHouse 中,随处可见 Alpine.js 的应用:

Alpine.js 可以很轻松让一个不熟悉 Webpack 等前端构建工具的后端工程师,在自己的应用中实现双向绑定。对于后端工程师来说,这个工具你们不可错过。

总结

NESHouse 的技术栈相比于很多复杂的应用来说,十分的简单,仅仅是 Leancloud + Agora 就可以完成几乎所有功能,但我相信,这样的技术架构选型,对于一些不需要那么大计算量、没有那么高业务负载的项目而言,是有帮助的。就算你有屠龙技,又何需在杀鸡之时用它呢?

大家好,我是白宦成(@bestony),前几天在 B 站直播写 ClubHouse 复刻版的开发者。当然,除了这个身份,在真实生活中,我还是 Linux 中国开源社区的技术负责人,负责开发我们自己的自用工具和平台。

作为一个 indiehacker(自诩的),我想和大家一起来复盘一下,这一次的直播活动和意料之外的爆火。

为什么要做 NESHouse

我其实想到复刻 ClubHouse 的时间是非常早的,我是在 2 月 1 日拿到了 ClubHouse 的邀请码,在试玩了一段时间以后,就觉得这个软件还不错,理念很有意思,但并没有太在意,放在了一边。可到了晚上,因为知道 Elon Musk 要来做分享,作为一个比较欣赏他的人,我自然不能错过,但遗憾的是,当我打开 ClubHouse 的时候,已经有太多的人涌入这个 App,几乎无法使用,总是不停的卡顿。

这时让我产生了怀疑:这个东西到底有多少的工作量?为什么这么容易性能卡顿?

结合实际的使用发现,有些时候,我可以正常聊天,但是却会报错,可以发现问题不在语音服务,而是在 ClubHouse 自身的业务能力不足以支撑超过预期的访问量

我上一份工作是在一家云计算企业工作,所以相对来说,对云计算产品有一定的了解。在我看来,这样的一个产品的增量,很难把现有的云计算产品的服务容量打穿,你能想象 ClubHouse 把 AWS、GCP、Azure 等云服务厂商打穿么?

我觉得,要么是开发者的大规模服务的架构经验不足,虽然用了云,但是没设计好,无法充分适应弹性;要么是开发者没有对超过预判的访问量做的预案不足。

这就让我思考,我能否复刻一个 ClubHouse?用一些更加具有弹性的服务?给大家打个样? 云计算是好,但用起来也要姿势对,才能不出问题。

72 小时复刻一个 ClubHouse,是一个什么概念?

既然要复刻项目,自然要做的不能和碰瓷的一样(这里鄙视几家碰瓷的 App,拿很久之前写的具备了语音聊天的 App,来碰瓷 ClubHouse)。

但我又不希望在这个事情上花费太多的事情,我还有很多更重要的事情要做,所以我选择了 72 小时。48 小时或 24 小时是一般的黑客松的时间长度,但我确实又不熟悉这个项目,所以用 72 小时比较稳妥。

于是便立了一个 Flag ,说我要在 72 小时内,复刻一个 ClubHouse。立了个 Flag,说干就干。关于这 72 小时,我希望可以强调两点,也希望这两点能够帮助到你。

1. 明确自己要做的和不要做的

我的时间和精力以及资源都有限,所以并不是什么东西我都能要的。比如在做复刻的时候,考虑到我如果开发原生的 App 或者小程序,就需要提交审核。那我就不能选择做 App,不然 72 小时到了,审核还没过,就食言了。也是出于审核的考虑,我最终选择了使用 Web 的方式来开发 NESHouse

而到了具体的功能特性层面,受限于 Web 和 App 的机制不同,我很难要求用户必须做什么样的操作,也很难确保 App 响应什么样的功能,因此,我对于 ClubHouse 的功能进行了一些删减,邀请上台之类的功能,我就选择性的先不做,将重点放在更加重要的功能中。

在开发黑客松项目的时候,一定要先想清楚自己要什么,不要什么,这样才能确保自己在给定的时间内完成自己的工作。不然大概率会发现时间马上要截止,但核心功能还没有研发完成。

2. 选择一些新的、以后可能会用到的技术

在这次项目开发的时候,我选择的前端技术栈并非我过去惯用的 React、Vue ,而是一个相对小众 JS 框架的 Alpine.js。

选择 Alpine.js 的原因很简单,我后续需要在其它的项目上使用这个框架,但我此刻确实也不熟悉。如果我在这 72 小时里把这个工具用了一遍,如果评估觉得不错,我就可以在后续的项目中使用,如果这次我用的不太好,那我损失的也只有 72 小时,比在正式项目中使用的损失成本要低很多

而在另外的两个服务,选择起来就简单多了:

  • LeanCloud 的云服务我使用了很多年,使用体验也很不错,而且他们这种 Serverless 云服务,可以让我在开发 NESHouse 的时候,免于去写很重的部署和基础逻辑,更加专注在业务逻辑上。
  • 音频服务我则选择了国内用户比较多,开发起来也比较方面的声网,声网的 API 比较简单, NESHouse 中的声网音频接入只用 4 行代码就实现了。

除此之外,便是使用了 NES.css 这样的 CSS 框架,来让这个项目更加的有趣,更加的 Funny。

对于开发黑客松项目的时候,可以想想自己能否接受这一次的失败,如果可以接受自己的失败,不妨将这次黑客松看做是一次玩的机会,玩一玩新的技术,就算失败了,也不过是损失给定的时间。但如果你在工作项目中出现了问题,损失可就大了。

总结

72 个小时的复刻对于我来说不算难,实际上我也只花了 55 个小时就复刻成功了。但更难的,是如何让一个开源项目持续的成长下去,持续的获得用户、获得关注。

最后,大家感兴趣的话,可以移步复刻这个项目,看看你能不能做一个自己的 ClubHouse: https://github.com/bestony/neshouse

2020 年 7 月 21 日,Linux 中国翻译团队 LCTT 旗下的第一个特别兴趣小组(SIG)—— LCRH,在红帽公司的鼎力支持下诞生。LCRH 的目标是翻译红帽公司《代码英雄》播客的脚本为适合国人阅读理解的中文脚本。

而到了半年后,LCRH 翻译的中文脚本已经正式更新发布了前三季节目,共计 24 篇文章,时长约 12 个小时,篇幅长达 25 万字,堪比一本长篇小说!

《代码英雄》的英文名为《Command Line Heroes》,作为红帽(Red Hat)公司精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者们是如何彻底改变技术前景的真实史诗。在这一目前仍在持续更新的系列播客中,红帽公司邀请了诸多亲历了开源技术发展史上一些关键事件的人物和代表性的业界技术领袖,来一同探讨开源、操作系统、容器等或源远流长、或鲸吞天下的开源技术。在将这个播客在引入中国时,红帽公司希望其能展现出这些顶级黑客、开发领袖的英姿风貌,因而将其中文名称定名为《代码英雄》。

让这些代码英雄的风貌传播给中国开源和技术爱好者的,是来自 LCRH 的 30 多位贡献者,他们通过自己的辛苦努力,对每一篇文章都经过多人、多次的反复斟酌,力求将代码英雄们的史诗传奇介绍给国人,带给广大的技术开发者。

以下是我们已经发布的前三季的《代码英雄》,更多精制译文正在贡献者们的努力下逐渐加工出来。

在 LCRH 的代码仓库中,记录了 35 名贡献者的 460 次代码提交。这些贡献者们有的人尚在高校,有的人已从业多年;有的人身在中国,有的人求学海外。但对于开源技术的热爱、对于开源贡献的坚持,让他们造就了 LCRH,造就了中文版的《代码英雄》。

作为一个开发者,《代码英雄》所讲述的历史让我悠然神往,技术领袖们对开源和技术的观点使我可以高屋建瓴地看清乱花迷眼的技术本质。而这一切,都是由 LCTT/LCRH 的贡献者带来的,感谢这些可爱的贡献者!

《代码英雄》SIG 欢迎对于开源和技术感兴趣的你,参与到我们当中来,和我们一起贡献代码英雄的世界!你可以在 QQ 中搜索群 940139452,加入我们,参与贡献,具体贡献流程可以进群后了解。

除了《代码英雄》SIG,如果你对技术翻译感兴趣,也愿意以这种方式参与开源贡献,也欢迎加入到 LCTT(Linux 中国翻译团队)当中来。同样的,在 QQ 中搜索群:198889102 即可加入我们,加群时请说明是“志愿者”,并在加入群后修改群名片为你的 GitHub 的 ID,参与贡献!

LCTT 的 CI 已经在 Travis CI 上运转了多年,一致保持着良好的使用体验。自 2019 年 Github 推出了自家的 CI 工具 Github Action 后,我们就在考虑将 CI 从 Travis-CI 迁移到 Github,以降低维护和沟通的成本,并借助于 GitHub Action Marketplace 实现更强的功能。

项目首页

最近,因为 TravisCI 屡屡部署出错,而我们的账户因为使用的较多,已经超出了免费使用的限制,以此为契机,将 CI 从 Travis CI 迁移到 GitHub Action。

Travis CI 的提醒

项目介绍

Translate ProjectLCTT 翻译组的主要协作项目,几百位译者通过 GitHub 进行围绕开源、Linux、软件工程等领域的文章翻译,从 2013 年来,累计了大量的提交,致使项目下有非常多的文件。

Translate Project 借助于 CI 帮助译者对基本的文章格式和拉取请求进行检查;并定时执行命令,以进行所有的申请检查,对于超时未完成翻译的工作进行回收;对于文章的状态进行标记,生成相应的徽章。

生成徽章

迁移思路

Travis CI 和 Github Action 在使用方面,其实总体差异不会太大,都是基于 YAML 文件格式来编写配置文件。不过,和 Travis CI 不同的是,Github Action 支持多个不同的配置文件,因此,你可以根据不同的场景,设定不同的配置文件,降低单个配置的文件的复杂度。

此外,由于我们的脚本中依赖了一些 Travis CI 的环境变量,也需要将其替换为 Github Action 中的相应环境变量,从而确保脚本可以运转。

改造实践

1. 分析之前的 CI 流程

我们在 TravisCI 上的 CI 配置文件如图:

配置文件

总体可以分为三块:

  1. 命令区:说明了安装阶段和执行阶段的操作有哪些
  2. 条件区:指定了这个配置文件在哪些条件下会生效
  3. 部署区:写明了构建产物如何进行部署

在命令区中,有预置的安装过程和后续的执行过程。在安装过程中,安装了一些依赖,并将当前的 pages 资源克隆到本地,以继承上一次构建生成的资料。

在条件区则指明了仅作用于 master 分支。

在部署区便是将前面命令区的执行结果进行部署。

基本流程

在实际的执行过程中,还会根据环境变量不同,决定是否要执行特定的命令,这部分在后续的改造过程中,就可以调整部署,拆分到不同的文件中。

构建流程

2. 直接套用配置文件

在完成了基本的分析后,就可以建立新的 Action 配置文件了。由于基本的语法很类似,对于其中的不少内容可以进行直接套用。

比如,我们的配置文件在直接套用后,结果如下

直接套用后的结果

直接套用的文件已经可以直接运行,不过,这里有很多不满足需要的地方,所以需要做一些修改。

3. 恢复 Travis CI 的环境变量

由于我们使用的 Badge 等生成脚本并非我所编写,所以在这一次的迁移中,并不打算对齐进行调整,以避免出现故障。而脚本中依赖了一些变量,需要将其重新设置出来。

Github Action 提供了一些方法,可以让你手动设置环境变量。你可以在你的构建的步骤中,加入如下代码,从而在构建环境中设定 TRAVIS_BRANCHTRAVIS_EVENT_TYPE 环境变量,确保你可以使用这个环境变量。

 - name: Set ENV variables
        run: |
 echo "::set-env name=TRAVIS\_BRANCH::${TRAVIS\_BRANCH:-$(echo $GITHUB\_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}" 
 echo "::set-env name=TRAVIS\_EVENT\_TYPE::$(if [ "schedule" == "${{ github.event\_name }}" ]; then echo "cron"; else echo "${{ github.event\_name }}"; fi)"

此外,由于 set-env 这个方法相对比较危险,你还需要在环境变量中,开启危险函数的执行。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ACTIONS\_ALLOW\_UNSECURE\_COMMANDS: true

4. 拆分配置文件

Github Action 和 TravisCI 不同的一点是你可以将你的 CI 文件拆分成多个文件,从而降低每一个单独的配置文件的复杂度。

根据前面对于流程的分析,可以将我们的 CI 流程拆分成三个部分:

  1. 生成 badge 文件,应当跟随每一次提交进行
  2. 生成 status 文件,执行时间较长,可以定期执行
  3. 根据拉取请求内容进行整理,做核验

则将我们的配置文件拆分成三个不同的文件:

也得益于拆分开,则在 checker 中就可以免于安装一些必要的依赖,从而精简 CI 流程,提升 CI 的执行时间。

5. 测试 CI 的运行情况

在完成了配置文件的编写和拆分后,就可以进行本地的执行测试。Github Action 写完了,难免要执行一下,确保整个流程是正常的。

这个时候你可以安装工具(https://github.com/nektos/act),来在本地执行 Action ,从而确认你的代码执行是正确的。

如果你是 macOS ,只需要执行 brew install act 就可以安装 act 工具,来完成 act 的安装。

安装完成 act ,就可以通过执行 act 命令来在本地执行 Action ,比如,执行 act pull_request 来触发 GitHub 的拉取请求事件

通过本地测试后,再将你的配置文件推送到 GitHub 上,进行生产环境的测试即可。

6. 移除 Travis-CI

通过上述的一些步骤,我们完成了从 Travis CI 到 GitHub Action 的迁移,此时,就可以移除项目根目录中的 .travis.yml 文件,彻底关闭 Travis CI。

7. 替换环境变量

在完成了基本的迁移后,需要对代码中的一些历史问题进行修复。在第三步中,我们对于 Travis-CI 的环境变量进行替换,但长期维护的项目应当尽量将这些未标注上下文的信息替换为有文档标注的,因此,我们需要将其替换。

替换环境变量主要依赖 Github 官方的环境变量说明,你可以参考官方文档

简化后,配置文件从之前的 27 行,减少至 17 行,变得更加的精简、易懂。

name: LCTT Article Checker

on:
  pull_request:
    branches: [master]
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      PULL_REQUEST_ID: ${{ github.event.number }}
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: "checkout master branch & return to pull request branch"
        run: CURRENT=$(echo ${{github.ref}} |  sed "s|refs/|refs/remotes/|") && git checkout master && git checkout $CURRENT
      - name: run check
        run: sh ./scripts/check.sh;

8. 修改 GitHub 的分支保护条件

为了确保修改符合标准,我们限制了新的拉取请求必须通过 CI 检查,才能合并进入 master 分支,因此,也需要修改相应的分支保护规则,确保设定相应的保护。

一些注意事项

1. 环境变量不同

如果你依赖了环境变量,则需要进行相应的修改。或者可以像我一样,先通过 set-env 来让本地拥有临时的环境变量,后续再逐步进行迁移。

2. Action 运行依赖要注意安全

Action 执行过程中会有两个部分。Action 本身流程依赖于 master 分支,但执行过程中调用的脚本是根据源决定的,因此,从安全角度来看,你应当尽可能将所有的流程放在 Action 中,而不是放在你的源码目录中。

3. 如何触发 CI 的拉取请求检查?

在进行拉取请求测试的时候,需要不断触发不同的提交 ,你可以通过执行 git commit --allow-empty -m "Trigger notification" && git push 来触发一个空白的提交, 推送到 Github 后,就可以再次触发拉取请求的构建,提升构建的效率。

总结

通过对 TravisCI 的流程整理、代码修改等流程,我们将之前的 Travis-CI 迁移至速度更快、性能更好的 GitHub Action ,一方面可以优化我们的工作流,另一方面,也让我们的代码更加简洁明了。

对于还在使用 Travis CI 的项目来说,也可以考虑迁移到 GitHub Action 中,来优化自己的工作流。

参考阅读

openEuler 是什么?在 2019 年 7 月 19 日,华为宣布要在年底正式开源 openEuler 操作系统;在半年后的 12 月 31 日,华为正式开源了 openEuler 操作系统,邀请社区开发者共同来贡献。

一年后,截止到 2020 年12 月 25日,openEuler 已经拥有了 3 万社区用户,2 万多个合入的 拉取请求 Pull Request ,2000 多名社区贡献者,7032 款社区软件,75 个特别兴趣组(SIG)以及 7 个商业发行版。不仅如此,openEuler 还在系统主体之外,开源了虚拟化平台 StratoVirt、容器引擎 iSula 等重量级软件。

openEuler 是发行版,还是...

和其他发行版不同,openEuler 的开场并不是以发行版开场的,而是从一个更加深刻的问题开始的——“操作系统有创新么?”。这个答案是肯定的,近些年来,无论是内核的架构还是应用组织的方式,都在不断的发生着创新和变化。但这些创新又好似离我们很遥远,也没有听到谁在实际生产环境中应用。这背后不是开发者的不努力,而是操作系统开发和交付的问题。

openEuler 技术委员会主席胡欣蔚拿线下的物流供应链举例,一条供应链是以满足客户需求为目的,包含了所有与满足客户需求相关的环节,从生产、运输、仓储、零售一直到最终的顾客,而与之类比的软件开发供应链,则由软件组成的相互依赖(构建、运行、代码的复制粘贴、定制化)形成的复杂关系网络被称为软件供应链。过去的开源软件把软件的交付终结于某一个特定的发行版,这带来了一些便利,简化了供应链的管理,相应的,也为软件开发的整体流程带来了单点故障的可能。

openEuler 技术委员会主席胡欣蔚

为了解决这个问题,openEuler 不是先做操作系统,而是先对软件开发供应链进行梳理,并将整个供应链梳理开源出来,让开发者的软件可以更好的交付给用户,让用户可以更好的把需求反馈到开源软件的上游社区。整个生态中开发者的需求、用户的需求都可以在这个供应链中得到满足。

而也正是这样的供应链,为 openEuler 带来了更多的可能,各个开源社区、合作伙伴,可以根据自己的需求,结合所在的行业和领域,打造出一款专精于领域的发行版。

不仅如此,供应链的思维,也让胡欣蔚可以重新思考云原生这个问题——“只有云才需要云原生么?”,答案显然是否定的。所有的数字化转型领域,都会需要云原生的这些特性。如何让这些边缘计算设备、端设备享受到云原生中的交付、迭代的性能,也是 openEuler 在关注的。openEuler 所特有的供应链,让操作系统的打包和精简变的更简单,可以根据设备不同的类型、场景整合出适合相应场景的操作系统,从而让这些新特性,可以不只交付给云,更可以交付给边和端,云边端一体为行业和业务创造价值。

openEuler 是操作系统,还是....

openEuler 广为人知的是一个新的发行版,一个 Linux 操作系统,但对于 openEuler 自己来说,操作系统不过是一个创新的产品的承载平台。在胡欣蔚来看,如果一个平台没有创新,则这个平台没有未来;如果一个创新没有好的平台去落地,那这个创新不过是无根浮萍,毫无意义。对于开发者来说,openEuler 就是这样一个孵化和培养创新的平台

胡欣蔚做了个比喻,“openEuler 就是 Apache 基金会 + CentOS 操作系统”。 CentOS 操作系统是一个著名的服务器系统,而 Apache 基金会是一个非常善于对新项目进行培育的基金会。openEuler 的操作系统,只是为了让创新可以有一个落地的平台,让创新有价值,而 openEuler 背后,是一个创新的平台、一个创新的土壤。

在这片土壤中,诞生了一些非常有意思,同时有具备使用价值的特性,比如跟随 openEuler 一同开源的 A-Tune,将 AI 的技术引入到系统的调教和优化过程中,用机器智能进行优化;比如开源的容器引擎 iSula ,让容器的运行可以更加的轻量和简单,从过去的只能运行于 x86 服务器,到现在可以应用在不同的边缘计算设备;比如 Bisheng JDK ,基于 specjbb 基准测试,相对 openJDK 性能提升了 20%;比如 StratoVirt,是基于 rust 语言开发的轻量级虚拟机,相对 QEMU 资源占用减少了80%,启动速度提升了 10 倍。

这些小的创新,让 openEuler 从一个普通的发行版,变成了一个远超过去的操作系统;而 openEuler 的孵化机制,可以让更多的有用的特性,从需求的收集,到发布到用户端,更加快速和方便。

行业在演进,操作系统和应用之间的分界线,开始变的更加的模糊,操作系统要做什么?应用要做什么?很难有一个一概而论的回答,但可以肯定的是,无论什么样的变更,都是希望这个行业可以有更大的进展,每一个行业中的开发者,都可以有更多的时间和精力去做更加核心的业务逻辑的开发。

openEuler 是软件,还是....

openEuler 不仅仅是一款软件产品,为什么 openEuler 会出现?有了数百款发行版的 Linux 世界,真的缺这样一款操作系统么?

答案是肯定的。

提及 openEuler 的诞生,胡欣蔚回顾了自己的过去,早在 2013 年,他就开始参与 ARM 服务器的构建,彼时 Linus Torvalds 对于 ARM v7 架构的评价刚刚过去不久,ARM 芯片应用在通用计算领域也只是刚刚开始,整个行业方兴未艾。他通过研究发现,整个行业的操作系统都存在一个普遍的问题:只适配于自家的芯片和计算平台,这使得应用开发者在开发的时候,需要根据不同的芯片来进行适配,大大的降低了开发者的效率,将更多的精力放在适配,而不是业务逻辑的研发上。

在他看来,这样薄的操作系统,无法为业务创新和行业的创新提供价值,而想要促进行业的前进,操作系统的变厚、变强是必不可少的,必须要像 x86 服务器一样,一个版本足以支撑所有厂商的 ARM 服务器,才能真正的促进 ARM 在通用计算领域的蓬勃发展。

也正是因为从那时开始的努力,经过了多年的耕耘,如今在 openEuler 上可以有所收获,当年的选择也无疑是正确的。如今的 openEuler 可以完美的运行在华为自家的鲲鹏处理器上,更是可以支撑多家的 ARM 服务器。不仅如此,一些科研院所,比如国科大的“一生一芯”项目,也被 openEuler 很好的支持了。对于开发者来说,使用的是 RISC-V 架构的芯片,也可以完美的支持 openEuler。未来,openEuler 将会从系统软件的角度,打通不同算力,让软件开发者可以在一个更加简单的操作系统之上,进行技术的创新。

openEuler 还可以是什么?

openEuler 的过去,是我们熟悉的 Linux 发行版,是我们所不熟悉的创新平台。而未来,openEuler 可能是什么?

胡欣蔚也向我们介绍了他的一些想法,在未来,openEuler 会在当前已有的基础之上,投入更多的精力去做一些普通开发者、厂商所无法实现的特性。比如在操作系统层面,提供秒级内核切换能力,让那些过去不敢升级、不愿升级内核的老旧系统,可以通过 openEuler 提供的特性,实现秒级的内核切换。在系统几乎不受影响的情况下,完成底层内核的切换,让老系统也可以享受到新内核提供的特性。也会花更多的精力,在 openEuler 社区的治理上,让 openEuler 社区可以有更多的用户,以及更多的开发者,让 openEuler 造福更多的企业和个人用户。

未来,openEuler 会出现在我们所熟悉的云计算和边缘计算上,到时候,我们再来看看,openEuler 还可以是什么。