Rust发布团队如何保证每六周发布一次编译器
#rust #blog
这篇文章是RustFest 2019中的一次分享，主要讲述了Rust发布流程是如何工作的，以及发布团队为什么要这么做。在过去几天发布的1.39版本中包含了大家一直期待的功能，在此前六周发布的1.38版本中包含了几十万行代码的改动，发布后发现了5个问题，有两个问题影响到了代码，另外三个是性能方面的问题。
在此前的1.37版本中，改动了几万行代码，有三个问题，在更早的1.36版本中只有四个问题。我想解释下为什么我们会进行如此快速的发布，以及过程中遇到了哪些问题，我们如何将问题扼杀在摇篮里。
为什么我们会每六周发布一次呢？这是个有趣的问题，很少有编译器有如此短的发布周期（原来Python的发布周期很短，后来改为一年了），这主要是因为我们没有发布压力。如果某个feature没有准备好发布，我们就会delay它几周时间，没有人会关心它是否在今天或者一个半月内要稳定下来。
当然我们也尝试过一个长的发布周期，特别是跟editon一起发布，但是这并不适合我们。稳定版editon在12月初发布，而9月份可能我们还对如何让模块正常工作存疑。而且这让会导致一些新的特性来不及经过nightly检验就匆忙发布，用户也无法对其进行测试，这样会破环我们许多内部的流程。
另外一个问题，我们如何及时发现并解决问题呢？答案是测试，我们有大量的测试，测试编译输出和异常信息，我们通过60个CI构建流去运行大量的测试，但是这并不够，因为测试并不能覆盖所有Rust的工作场景。
所以我们开始让编译器去编译它自己，每次发布前我们都用前一次去编译它。在nightly发布前我们用beta去编译，在beta发布前我们用stable去编译，stable发布前我们用上一个stable去编译，这会让我们捕获到一些特殊的场景，由于编译器代码库使用了许多不稳定的功能，而且编译起的代码库还有点旧，因此我们可以捕获一些极端情况，但是并不能覆盖所有内容。
我们从开发者拿得到bug报告，大部分是nightly的bug，而不是beta的，因为大部分人使用的是nightly而不是beta，我们也不能让用户去测试beta，即使我们要求，开发者也不会去测试的。我们想了一个办法，我们可以去测试用户的代码，虽然这么做很烧钱，这个项目就是Crater。我们把crates.io上和Github上带有Cargo.toml的项目克隆下来，对每一个项目我门运行两次cargo test，在stable上运行成功，但在beta上运行失败，这就是个问题，然后我们会记录下这个问题。
在1.39发布时我们在46个crate收集到了失败的报告，然后发布团队会对每个问题进行分析，然后去解决。1.39还算好的，在1.38版本我们收到了600个crate失败的报告，如果没有Crater，可能你在升级后就会编译不通过了，这会让开发者丧失对稳定版本的信心。
我们知道这样做不够完美，因为我们没法测试私有项目和Gitlab上的项目，而且每个项目都需要在sandbox中运行。Crater并不是一个可以长期永久扩展的东西，它使用了大量计算资源，太烧钱。
这些确实是一些需要解决的问题，不过目前它起到的效果很好，通过它在几百个crate中发现了几十个问题，这也是我们可以快速发布的原因之一。
From 日报小组 格朗
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：
评论区
写评论还没有评论