http://www.xiaoyenzi.com

IPFS相关——IPFS发布流程改进

文章来源:金色财经

作者: IPFS原力区

本文由IPFS原力区收集译制,版权所属原作者

“go-ipfs引入了一个新的发布周期和过程,以确保更可靠和更频繁的发布。”

IPFS正在成长和成熟。在我们的网络中我们看到了越来越多的用户,并且已经意识到有必要升级我们的发布流程,以便定期交付更适合生产的产品。之所以这样做,是因为我们发现在最近三个版本中出现非常多的regressions(回归,即倒退)(自修复以来)。我们不希望这种情况再次发生,所以我们正在采取保障措施,以便最大限度地在倒退之前把握住机会。

以下是发生的事情:

-- go-ipfs 0.4.19在高负荷下使用时存在多重regressions(回归):

-- docker容器中的回归(由#6040引入),在更多的生产环境中测试go-ipfs docker映像可以捕获该回归。

-- 位交换中的CPU利用率回归只在非常高的负载下出现。在生产负载下进行测试就会发现这一点。

-- DHT和QUIC模块中的Panics只在重负载下出现。

--go ipfs 0.4.20有一个回归,在同一个add命令中添加多个独立文件不起作用(#6254)。后来又增加了一个回归测试,但通过更好的跨应用程序测试也可以发现这一点。

--go-ipfs 0.4.21在位交换中有两个性能回归:

-- 吞吐量回归应该被回归测试捕获(现在已经测试了),但是如果发布测试过程更长,下游用户几乎肯定会注意到它。

-- 只有>10000个对等点出现的CPU利用率回归。只有在某些生产系统的重载下才会出现。

我们发现了两个根本原因:

1、与前几个季度相比,开发速度有所提高,但没有与我们的测试实践相匹配的改进。今年,一些大型的重构软件触碰到了关键点,但是测试很差。

2、在没有大规模测试或网络模拟基础设施的情况下,go-ipfs的网络规模和生产需求显著增加。在过去,所有的生产规模测试都是通过将自定义go-ipfs构建部署到引导程序或网关并观察其行为来完成的。

为了解决这些问题,我们暂停了所有非bug修复go-ipfs发行版,因为我们改进了测试实践,构建了测试和网络模拟基础设施。这对于确保改进的测试,在面对新特性和迫切的性能改进时不会成为第二个关注点非常重要。

然而,即使使用我们当前的测试实践,这些回归也应该通过严格的发布前测试得到。更好的发布过程(例如,减少补丁发布的能力)还将使我们能够快速发布这些回归的补丁,并使我们的用户能够快速部署这些补丁,而不必担心其他不相关的更改的潜在影响。

因此,除了改进我们的测试之外,我们还引入了一个新的发布过程,以确保在尽可能多的环境中测试了版本,并且我们可以在不等待整个发布周期的情况下快速发布错误修复。

发布过程更改

我们对发布过程做了三个具体的修改:

1、为了解决稳定性问题,我们引入了一个新的发布过程,该过程涉及到在各种生产环境中广泛地测试发布,包括早期测试人员。

2、为了解决缓慢发布的问题,我们引入了6周的发布周期。

3、为了解决bug修复缓慢的问题,我们已经切换到semver并引入了补丁版本。第一个补丁版本将是0.4.22,下一个特性版本将是0.5.0。

新版本发布流程

新的版本发布过程包括5个阶段:

1、自动测试- go-ipfs CI通过。

2、内部测试- go-ipfs针对IPFS基础设施、内部测试和仿真工具以及船厂应用程序进行测试。

3、社区开发测试——go-ipfs由社区在开发环境中进行测试。

4、社区Prod测试- go-ipfs由社区在生产环境中进行测试。

5、释放- go-ipfs被释放。

如果我们在发布过程中合并任何重要的修复,我们将从0阶段开始,对已经完成一次的阶段进行压缩的发布过程。我们预计阶段1-3平均需要一周的时间,这意味着从删减到发布一个新版本需要3周的时间。

第0阶段-自动化测试

当我们努力保持master green时,问题偶尔会被忽略(通常是由于错误的测试或CI中没有注意到的问题)。在我们发布一个分支之前,我们希望master是绿色的。

这是我们派生出一个发行候选版本的阶段。

第1阶段-内部测试

这个过程的第一个真正的阶段是内部测试。在此阶段,IPFS团队将针对IPFS船厂中的应用程序、我们正在构建的一些新的测试和仿真基础设施以及IPFS项目生产基础设施的子集(引导程序和网关)测试候选版本。

这个阶段允许我们在一个受限的控制范围内快速发现、诊断和修复问题,然后再要求更广泛的社区开始测试。

第2阶段-社区开发测试

在这个阶段,我们向社区宣布即将发布的版本,并要求进行beta测试。这个阶段的存在是为了给一个新的IPFS发布候选版本提供一些尽可能多的环境下的低风险测试。

这也是我们让早期测试人员参与的第一个阶段。在这里,我们要求他们在他们的开发基础设施中测试go-ipfs版本,并与我们一起解决任何问题。

第3阶段-社区产品测试

一旦go-ipfs发布候选版本在开发环境中进行了彻底的测试,我们就要求早期测试程序的成员将候选发布版本部署到其生产环境的一个子集。这个阶段让我们有机会对生产工作负载进行测试,同时保留快速回滚更改和修复在最终版本发布之前可能出现的任何问题的能力。

第4阶段-发布

在第4阶段,我们确保所有文档都已更新,最终版本将其发布给社区。

早期测试程序

我们正在引入一个早期的测试人员程序,该程序允许在生产中使用go-ipfs的团队自愿帮助测试开发和生产环境中发布的go-ipfs候选版本。当我们邀请整个社区来帮助测试版本时,早期测试人员计划的成员直接并积极地参与到每个版本中。

早期的测试人员将把候选版本部署到开发环境和prod环境中,对于他们注意到的任何倒退或性能变化,我们都会得到快速的反馈。这意味着在我们删除正式版本之前,我们可以从老用户那里得到一些快速的反馈,这些老用户可以和我们一起确保新版本不会在他们的系统中引入任何回归。

该计划目前包括:

InfuraTextilePinataRTrade (Temporal)QRISiderus发布周期

由于没有任何新功能,go-ipfs现在大约每6周就会发布一个新版本。具体地说,我们的目标是每隔6周发布一个新版本,然后在预期的3周内运行整个发布过程。

如果发布过程在预期的3周内运行或超过预期的3周,那么不管怎样,下一个发布的目标都将是在6周标记处进行分支。这样,即使我们不按时发布,我们仍然可以保持6周的发布周期。

补丁版本

考虑到这个发布过程中增加的结构和广泛的测试,如果出现关键回归,我们需要一种快速发布补丁的方法。如果我们在go-ipfs发行版中修复了一个关键的回归,我们将基于当前的稳定发行版为这个回归创建一个补丁发行版。

此补丁发布仍将经历一个简短的发布测试过程,但我们预计将花费2-3天,而不是几周。

1. 内部测试一天以内。

2. 早期测试人员项目成员进行生产测试1-2天。

注意:此发布过程不引入长期支持发布。补丁将只应用于最新版本,不会进行反向移植。此外,下一个功能版本可能会包含额外的错误修复,这些错误修复在补丁版本中并不重要。

Semver

这个发布过程最终将go-ipfs切换到semver。与许多1.0之前的项目一样,go-ipfs保留了一些较小的版本,用于重大的破坏性更改或重要的里程碑。然而,这意味着我们无法区分真正的补丁版本(应用于前一个版本的bug修复)和特性版本(次要版本)。

这意味着将会持续在go-ipfs达到1.0之前:

小版本将不再标志着重大的里程碑或重大的变更。相反,小版本将是普通的特性版本。补丁发布现在只是以前稳定版本的补丁。作为一个历史上的小插曲,我们抱着一个有点浪漫的希望,即0.5.0将标志着功能的完整性(“beta”),并且在那之后的下一个非补丁版本将是1.0。然而,下一个特性版本0.5.0并不意味着任何特殊的东西,也不会是一个重要的里程碑。

交流

在这个过程中我们有几个交流点:

当我们删除每个RC时,我们将创建一个相关的GitHub版本。在第0阶段,我们将使用版本检查表的副本创建一个问题。在第二阶段,我们将在IRC/Matrix上发布候选版本。在第三阶段,我们将在IRC/Matrix和Twitter上向更广泛的受众宣布发行候选版本。在第四阶段,我们将继续发布一篇博客文章,宣布此次发布的重点了解更多

如果你有兴趣了解这个发布过程的实际情况,这边为最新的补丁发布(0.4.22)测试了完整的(而不是补丁)发布过程:#6506。

如果你想阅读官方的发布过程,你可以在docs/release .md中找到。

最后,如果你正在生产中使用go-ipfs,并且希望加入早期测试人员计划,可阅读docs/EARLY_TESTERS.md。

—end—

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。