前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >你想知道,Microsoft Edge这种巨型项目是如何进行版本管理的吗?

你想知道,Microsoft Edge这种巨型项目是如何进行版本管理的吗?

作者头像
用户1158055
发布2021-07-14 13:51:17
1.1K0
发布2021-07-14 13:51:17
举报
文章被收录于专栏:郭霖郭霖

本文同步发表于我的微信公众号,扫一扫文章底部的二维码或在微信搜索 郭霖 即可关注,每个工作日都有文章更新。

不知道你有没有好奇过,像Microsoft Edge这种巨型项目是如何进行版本管理的?

当然关于这个问题我就需要先解释一下,因为Edge是多么巨型的一个项目很多人可能并没有概念。

事实上,其实我也没有概念,因为我知道自己接触的只是冰山一角,可能绝大多数人看这个项目的代码都像是在管中窥豹一样。

Edge是微软研发的一款基于Chromium内核的浏览器,而Chromium则是由Google推出的一个开源浏览器项目。

那么Chromium有多么庞大呢?很可惜,我没有找到最新的数据,但是根据2019年的数据,Chromium项目的总代码行数达到了3400多万行,纯代码行数(去除注释和空行)也有2500多万行。

毫无疑问,这简直就是一艘航空母舰,因此相信没有人敢说自己对这个项目是完全了解的。

而Edge相比于Chromium还会更大庞大一些,因为微软还会在Chromium的基础之上添加许许多多自己的功能。

那么再次回到开始的问题,你有好奇过像Edge这种巨型项目是如何进行版本管理的吗?

今天我们就来揭秘一下。

首先要说明的是,接下来我要讲解的Edge版本管理与发布规则并不是由微软发明的,而是遵循的和Google Chrome完全相同的规则(毕竟是基于Chromium内核的项目),因此不涉及任何微软的内部机密。

这套规则我认为是相当科学与成熟的,我敢肯定除了Edge和Chrome之外一定还存在大量成熟的项目也使用的是类似的规则。而对于一些还没有形成自己规则的小项目,我觉得正好可以趁此了解一下本篇文章中介绍的内容,让你们的版本管理变得更加科学。

首先跟大家介绍一下Chromium内核版本号的概念。

可能对浏览器比较关注的朋友或多或少有听说过,比如Chrome 80发布了,Chrome 90发布了这样的新闻。这个后面的版本号对应的就是Chromium内核的版本号。

许多国内浏览器也是基于Chromium内核开发的,它们有时也会在宣传时加上Chromium内核版本号的说明。

比如QQ浏览器是基于Chromium 70内核开发的。

360安全浏览器是基于Chromium 86内核开发的。

那么这个内核版本号是按照什么样的规则进行升级的呢?

其实很简单,根据Chromium的规则,每6周会升级一次内核版本号,雷打不动(从今年9月份开始,Chromium会将规则改成每4周升级一次内核版本号,不过由于是将来时,每篇文章仍然以每6周进行讲解)。

也就是说,如果当前最新的Chromium内核版本号是90,那么6周之后就会变成91,以此类推。

在这6周时间里,会有无数代码被提交进Chromium的主线代码仓库中,而这些代码变更也就会将成为Chromium 90与91内核之间的所有功能差异。

了解了这些内容之后,接下来我们回到Edge。

目前我所在的团队是微软的Edge Android团队,Edge Android版的官方上架渠道就只有一个:Google Play。(虽然在国内的一些手机应用商店也能下载到Edge,但是这些商店的版本有些可能是从其他地方爬来的,有些则更新不太及时)

如果你尝试在Google Play中搜索Edge,你会发现其实Edge并不是只有1个版本,而是会有4个。

这对于一些小白用户可能直接就给整懵圈了,搞这么多版本干啥,我都不知道该用哪个好了。

是啊,直接就上架一个稳定版不就好了吗?为什么还要分什么Canary、Dev、Beta版本?

这是因为,每个版本都有它们各自不同的作用,4个版本结合到一起则能让整个项目变得格外稳定和健壮。

接下来我就逐个介绍一下这4个版本它们分别的作用和存在的意义。 Microsoft Edge Canary

Canary是金丝雀的意思,这个单词在软件开发行业中很常见,但是真正了解它含义的人却并不多。

早期这个词汇是用在采矿领域里的。矿工会带着一只金丝雀进入矿坑采矿,由于金丝雀对各种的有害气体比较敏感,在人类发觉有害气体前,金丝雀就会先死掉,以此让矿工能够及时发现有害气体,尽早做出防护。

到了软件行业中,Canary也是同样的意思,它的主要作用就是让我们能够在很早期的时候就发现软件中存在的问题。

如果你选择成为Edge Canary的用户,那么你将能够在第一时间体验Edge中加入的各种最新功能。因为Canary的发布频率是每天发布一个版本。

也就是说今天我编写的某个功能,明天你就能在Edge Canary中体验到了。

当然,除了体验新功能之外,你还会体验到很多新Bug。因为正如刚才所说,Canary版就是用来在很早期的时候发现问题的,所以它相当不稳定。如果出现什么功能缺失或者崩溃的情况,请不要惊讶,我们也会根据用户测出来的各种问题及时进行修复。

不过这种版本发布频率可能并不适用于每个项目,如果是一些比较小的项目的话,一天时间可能根本不会有太大的代码变化,这样的话每天发布一个版本意义也不是很大。

而Edge则每天会有海量的代码进入到主线的代码库当中。现在的Edge是全平台共用同一套代码库的,每天会有来自PC端的代码更新,也会有来自移动端的代码更新,还会有从Chromium拉取下来的代码更新。所以,每天的Canary版本都会有许多不一样的地方,虽然我们也不知道具体有哪些不一样(毕竟每个人都只负责自己的一小部分),但神通广大的网友总是可以发现,并帮忙提出问题。

这也是Canary版本最大的意义所在。 Microsoft Edge Dev

Edge Dev和Edge Canary其实是有点类似的。从名字你就可以看出,它的目的也是为了让用户在早期的开发阶段就能体验到Edge的最新功能。

但是Dev版并没有Canary版那么激进,它不是每天发布一个版本,而是每周发布一个版本。

是的,它们的区别只有这么多。

但是别看就只是一个发布频率的区别,它们所面向的用户群体就完全不一样了。

Canary版面向的群体是那种发烧友级别的用户,他们愿意每天更新一个变化可能并不是那么大的版本,只是为了第一时间就能体验到Edge团队前一天开发出来的新功能。

而Dev版面向的用户群体则更加保守一些,每天一更新对他们来说太频繁了(我个人就非常不喜欢更新特别频繁的应用),每周更新一次,体验这一周以来Edge总体引入的各种新功能,对他们来说刚刚好。

另外,Dev版相比于Canary版也会稳定许多。如果你是一名Canary版的用户,今天本来还能正常使用着浏览器,结果明天更新了一个新版本,或许就会出现启动闪退的情况。

而Dev版出现这样情况的概率就会大大降低,因为它一周只会发布一个版本,Canary版上遇到的那些问题有很大的概率在Dev版上都会被修复,所以相对来说你可以比较放心地去更新Dev版。

总结一下,Dev版更加适合于那些既想要体验新功能,又希望版本能够比较稳定的用户。 Microsoft Edge Beta

如果仅从更新频率上来看的话,Edge Beta和Edge Dev的更新频率几乎是差不多的,Beta版也是每周发布一个版本。

但是,Beta版和Dev版的作用是完全不同的。

Beta在软件行业中通常就是快要发布的意思,主体功能已经稳定,也不会再发生什么大的变更,就差临门一脚正式上线了。

Edge Beta也是这个意思。

刚才有说过,Dev版每周会更新一次。在经历6周的迭代之后,这个Dev版就会转变成Beta版。然后Beta版继承Dev版的内核版本号,Dev版的内核版本号加1。

举个例子,比如Edge正在基于Chromium 90内核来开发新功能,开发6周之后,这个版本会变成Beta版,于是Edge就会发布一个基于Chromium 90的Beta版,同时正在开发的代码主线内核会变成Chromium 91。

在这种情况下,Canary和Dev版的用户很快就能体验到基于Chromium 91内核的版本了,而Beta版的用户才刚刚用上基于Chromium 90的版本。

Beta版的发布也就意味着这个开发周期中所有的功能都已经做完了,它接下来所肩负的使命就是将这个开发周斯中所做的这些功能稳定地交付给用户,而不是额外再引入一些下个开发周期中的新功能。

要知道,经历6周的迭代开发之后,功能性方面虽然已经是完善了,但是稳定性方面还没有任何保证,这也是Beta版的价值所在。

和Dev版类似,Beta版也是每周会发布一个版本,但是这些版本不会再增加任何新功能,只是会修复各种线上用户发现的Bug,以此不断提升Beta版本的稳定性。 Microsoft Edge

Beta版本再次经历6周的迭代之后,该修的Bug基本也就都修完了,那么当前的Beta版可以说是一个相当稳定的版本,它会转变成Microsoft Edge的正式版发布上线。

如果我们审视一下当前的时间节点,当第6周的Beta版转变成正式版时,其实也正是第6周的Dev版转变成Beta版时。这样Beta版又会开始一个新的6周的稳定性测试周期,而Canary和Dev则会开始一个新的6周的开发周期,以此不断往复。

所以,按照这种规则,假如你是一位Edge正式版的用户,目前你使用的版本是Edge 90,那么此时的Beta版一定是Edge 91,而Canary和Dev版则已经是Edge 92了。

这也是为什么说,Edge使用的这套版本管理和发布规则(也是Chromium使用的规则)相当成熟与科学,它保证了每一个发布出去的正式版本都是非常稳定的,并且每一个版本也都有充足的生命周期。

6周的功能开发加上6周的稳定性测试,使得所有应该发现的Bug在开发和测试阶段就已经发现并解决完了,因此可以放心大胆地上线正式版。相比国内一些之前比较热门的热修复技术,在海外一是不能用,二是也没有必要,因为即使不借助这些事后补救的黑科技,我们使用软件工程与管理的方式也可以很好地在事前就保证好版本的稳定性。

至于每个正式版本的生命周期其实也是一件很重要的事情。我发现我自己使用的一些App,完全没有任何规律性的更新节奏,经常是时不时给你来个新版本上线。

我通常是一个有更新必升的人,但是有些App今天升完之后,两天后又告诉你有个新版本上线,更新日志就是修复了一些Bug,升级完之后再过两天又弹出一个更新提醒,更新日志又是修复了一些Bug。

这种就不是一个出色的App应该有的表现,他们是在拿正式版的用户当Canary版去测试,时间久了我就再也不想升级这种App了,因为升完之后没过两天还会再让你升级。

而Edge的这种机制充分保障了每个正式版本的生命周期,它固定每6周更新一次,既不会更新的太频繁导致用户厌烦,也不会太久不更新导致用户流失,并且每次更新都对应了一个全新的Chromium内核版本。

所以,这4个版本分别的作用和面向的用户群体相信大家已经明白了。Canary版面向的是发烧友用户;Dev版面向的是既想要尝鲜又追求一定稳定性的用户;Beta版面向的是希望提前6周体验到最新正式版本,但能接受一定Bug的用户;正式版面向的则是最广大的普通用户群体。

现在你知道,像Edge这种巨型项目是如何进行版本管理的了吧。

介绍完了关于Edge的这些知识点,接下来再跟大家讲一讲现在移动端Edge的现状吧。

如果你是一位细心的用户,你可能会发现,目前Google Play上Edge正式版竟然还是基于Chromium 77内核的,而相比之下,Chrome已经是基于Chromium 91的内核了。

根据刚才6周升一版本的频率,77的内核差不多已经是Chromium两年前的版本了。

为什么会有这么大的差距呢?

这是因为,一开始PC端的Edge并不是基于Chromium开发的,使用的是微软自己的浏览器内核,而移动端的Edge则是使用的Chromium的内核。那个时候PC端和移动端的代码是完全不相干的,大家各做各的。

后来微软放弃了自己的浏览器内核,PC端的Edge也转向了Chromium,这个时候Edge部门就做出了要求全平台统一代码库的决定。

但全平台统一代码库并不是那么简单的一件事,这意味着移动端和PC端再也不能各做各的了,而是大家要统一步伐,统一进度,统一内核版本号。

于是,移动端的Edge从那个时候开始就没有再升级过Chromium的内核,而是花了近两年的时间去做了一个全新的全平台聚合的版本。它将会基于Chromium最新的内核版本推出,并且以后也会实时基于Chromium的最新内核同步推出Edge的新版本(最多可能会有几天延迟)。

而这样一个全平台聚合的全新Edge将会于本月下旬推出,到时候你们将会发现Edge的内核版本会从Chromium 77直接跃升至Chromium 92,相当于是一次革命性的升级。

不过,你也可以选择不用等到本月下旬,而是今天就去尝试全新版的Edge。因为根据刚才讲过的内容,Edge Beta版需要迭代6周之后才能转变成Edge正式版,也就是说现在Edge Beta早已是基于Chromium 92的版本,并且一直在测试当中了。

如果大家有兴趣的话,欢迎加入Edge Beta版的阵营,除了能体验最新内核的Edge之外,还能帮助我们测试出更多的问题,以在几周之后向广大用户发布一个更加稳定的正式版Edge。

Edge Beta的下载地址是:

https://play.google.com/store/apps/details?id=com.microsoft.emmx.beta

注:需手机可以访问Google Play。


本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2021-07-12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档