MariaDB 下载系统如何工作

我在 MySQL AB 的那些年里，有一个不幸的任务，那就是手动维护企业客户的下载页面。这涉及大量枯燥、容易出错的工作，几乎每次发布都会导致某种错误。我们的一些下载最终被网络团队编写的自动化系统取代，但浪费的那些时间仍然让我感到痛苦。所以当我加入 Monty Program 并看到我们的下载在 mediawiki 中手动维护时，我知道必须做出改变了。

Monty Program 和 MariaDB 项目的大部分网站都是用 Django 编写的，所以我从这里开始。我使用了我们现有的网站代码库，只是创建了一个新的 Django 应用程序用于下载。系统中涉及许多模型/表，但重要的有

• 版本：我们发布的所有版本的列表，例如 MariaDB 5.2.7、MariaDB 5.1.55 等
• 文件：构成发布版本的单个文件。
• 镜像：MariaDB 镜像的信息（名称、URL、位置）。
• 规则：这是系统的核心，控制文件名如何分配给发布版本及其各种其他属性，如操作系统和版本。

当 MariaDB 发布版本准备就绪时，我们的发布协调员会将文件推送到我们的主镜像，并告诉下载管理系统检查新版本。系统会扫描镜像并捕获新文件的信息（名称、大小、目录）。然后系统会按顺序遍历每条规则并检查其是否适用。

一条规则基本上是一个正则表达式，然后是一段要运行的 Python 代码。庞大的正则表达式总是很难处理，所以我们尽量让规则尽可能简单。例如，这是我们的一条规则。

名称： CPU – x86_64
正则表达式: .*x86_64.*
代码: file.cpu = ‘x86_64’

显然有些规则更复杂，但这是一个很好的例子，说明我们的目标是什么。它易于理解，如果需要修改，也可以轻松完成。代码段中的文件对象是一个帮助对象，通过隐藏底层对象的实际复杂性，使编写规则更容易。我考虑过使用某种规则引擎，但认为这会增加不必要的复杂性（这个问题下的最佳答案帮助我形成了这个观点： http://stackoverflow.com/questions/467738/implementing-a-rules-engine-in-python）

应用所有规则后，发布协调员会进行最终检查并发布版本。如果稍后出现问题，可以撤回整个版本或单个文件。

前端相当直观，没有什么可多讨论的，但这里有一些亮点

• 文件列表通过 ajax 加载，因此应用过滤器速度很快。
• 您的镜像首先通过查看您的国家，然后是您的大洲来选择。如果有人试图从 南极洲 下载，将选择一个随机镜像。

简而言之，这就是我们的下载系统的工作原理。如果有人对此有任何疑问，我乐意解答，可以在评论区或 Freenode 的 #maria 频道提问。