MariaDB Server 的挑战与愿景 - MariaDB.org

在 MariaDB 基金会，我们希望 MariaDB Server 成为开源世界的模范公民。目前，理想与现实之间存在相当大的差距。但这并没有阻止我们努力改进。在此，我将描述我们面临的一些挑战，并分享我们希望达成的愿景。

持续集成

一个痛点是开发分支的状态。一个模范公民（指项目）会确保该分支始终可以构建。每天，所有正在开发的功能都可以在所有平台上由社区进行测试。所有代码推送都只有在代码不仅能在单个开发者的笔记本电脑上编译通过，而且能在所有平台上编译通过，并且通过回归测试的前提下才能提交。这都需要在所有平台上完成。

我们尚未达到 MariaDB Server 分支始终在所有平台上通过所有测试的状态，但我们正在为此努力。每个开发者、每个贡献者都应该能够依赖主开发分支正常工作，这样我在开发时遇到的 bug 就只属于我自己。

我们的持续集成（CI）基于 Buildbot，理论上，它能帮助我们在成为模范公民的道路上走得很远。但在实践中，我们无法将所有提交都在所有测试中运行作为推送代码的先决条件。运行测试需要太长时间（几个小时），特别是偶发的失败更是一个挑战，因为它们不是每次都发生。

MariaDB Server 的核心作用是在用户环境中运行，并且 MariaDB Server 与用户的数据和软件的互操作性将始终至关重要。对于流行的 Linux 发行版和客户端连接器，我们会自己进行一些测试。然而，我们需要为有兴趣的各方提供参与我们 CI 流程的能力。

很难预测某个功能何时准备就绪

按照老派智慧，你不能同时确定截止日期、功能集和质量水平。只能从中选择两个。而老派智慧是对的。

然而，由于用户总是要求全部兼顾——功能、按时交付、没有 bug——我们将不可避免地需要在三者之间做出一些妥协。

这里的痛点在于就如何定义一个版本发布达成一致。我们不牺牲质量，但我们应该在固定截止日期发布，还是在实现特定功能集时发布？

这个讨论自 MariaDB Server 从 MySQL 分支出来后就一直存在。直到 MariaDB 10.1，我们都采用基于功能的发布模式。现在，人们普遍认为用户期望相对规律且频率较高的发布。自 10.2 版本以来，我们采用了基于时间的发布模式，取得了不同程度的成功。对于 10.6 版本，我们放弃了时间限制，再次转向了基于功能的发布方向。然而，间隔较长且不规律的基于功能的发布会形成一个恶性循环，为了再加入一个功能而进一步延迟发布，哪怕只是一点点。但一个版本不可能包含所有内容，我们不能试图创造德国人所说的“eierlegende Wollmilchsau”（会下蛋、产羊毛、产奶的猪）。一头会下蛋、产羊毛、产奶的猪只是一厢情愿。

错过一班列车代价高昂

但是基于时间的发布也有其缺点。如果某个功能在发布截止日期前没有准备好，它就必须等到下一个版本。这被称为“列车模型”。我们都讨厌错过列车。

不过，列车与列车不同。错过地铁或有轨电车远没有那么令人沮丧。你只需等五到十分钟就有下一班。看起来，将列车模型改为适应更频繁的发布——我们称之为“有轨电车模型”如何？——可能会显著减轻错过一个版本发布的痛苦。不幸的是，事情并非如此简单。

质量也需要时间

更频繁地发布与发布高质量、成熟的产品之间存在根本性的矛盾。首先，我们发布新 MariaDB 的 alpha 版本。一些用户开始尝试使用，他们发现并报告 bug。当涌入的 bug 数量逐渐减少时，我们发布 MariaDB 的 beta 版本。更多的用户下载并尝试，发现了更多的 bug 并进行报告。之后，我们发布 Release Candidate（发布候选版）版本，以触达更多用户——它被认为是接近生产质量，但尚未完全达到。在修复了最后的 bug 后，我们宣布这个新的 MariaDB 版本为 stable（稳定版，或 GA，通用版本）。

这意味着一个版本发布需要按照自己的时间表来成熟，我们不能仅仅为了节省时间而希望它变得 stable。但也许可以通过在第一次发布之前进行密集的内部测试来适当地压缩时间。理想情况下，密集的定向测试可以让我们快速通过早期的成熟阶段，在几天或几周内发现这些 bug，而不是几个月。

早期访问

然而，任何内部测试都无法告诉我们用户会做什么——新功能是否解决了用户的问题，是否适合用户的应用，是否达到了用户的预期。内部测试只能告诉我们一个功能是否按照我们设计的运作，但只有用户能告诉我们是否设计得正确。提供新功能的早期访问至关重要，以便发现并纠正那些内部测试无法找到的问题。