为了确保新的（或更改的）代码不会破坏任何东西，有一个全面的测试套件在 MariaDB Server 开发过程中运行以捕获回归。开发人员应在本地运行测试套件，并在将代码推送到远程仓库后，也要检查在 Travis CI 和特别是 Buildbot 上运行的更全面的测试也没有发现任何回归。然而，有时开发人员会粗心大意，犯错，不检查测试结果，急于将他们的代码更改推送到主分支，然后测试套件就会从那时起给其他人带来错误。理想情况下，应该有一个自动机制来阻止导致失败的代码更改。
2015 年 9 月，GitHub 宣布了一项名为“受保护分支”的功能。由于 MariaDB 的开发是在 GitHub 上进行的，我们一直想使用此功能。由于本文后面解释的原因，我们目前还无法完全开启它，但我们已经非常接近能够这样做。以下是受保护分支功能可能如何工作以及还需要完成哪些工作的总结。
要保护的 Git 分支：10.3、10.1、10.0 和 5.5
与一般的 git 仓库不同，MariaDB Server git 仓库没有 master 分支。取而代之的是每个主要版本都有一个分支。目前，仍在维护的主要版本从 5.5 到 10.2。新开发在 10.3 版本上进行，它将成为下一个主要发布版本。这些分支就是要保护的分支。所有 bugfix 和功能开发都从主要发布分支派生出来，它们必须始终是完美的并能通过测试套件，这样如果开发人员在新代码中引入了错误，当测试套件不再通过（从绿色变成红色）时，开发人员应该能够意识到他们自己的更改破坏了一些东西。
如何使用受保护分支
实际上，如果开发人员在受保护的分支上修改了某些内容并尝试将其推送到 GitHub，它会看起来像这样：
$ git push remote: error: GH006: Protected branch update failed for refs/heads/10.3. remote: error: Required status check "continuous-integration/travis-ci" is expected. To github.com:mariadb/server.git ! [remote rejected] 10.3 -> 10.3 (protected branch hook declined) error: failed to push some refs to 'git@github.com:mariadb/server.git'
启用分支保护后，强制推送也会被禁用
$ git push -f remote: error: GH006: Protected branch update failed for refs/heads/10.3. remote: error: Cannot force-push to a protected branch To github.com:mariadb/server.git ! [remote rejected] 10.3 -> 10.3 (protected branch hook declined) error: failed to push some refs to 'git@github.com:mariadb/server.git'
除非测试套件运行已通过，否则 GitHub 将自动阻止开发人员在受保护的分支上推送更改。对于 MariaDB，这意味着 Travis CI 运行必须已完成并无错误通过。
在 github.com 网页上，这将可见，以便在确认（通过 Travis-CI）测试套件通过之前无法合并 PR。
如果测试套件已通过，PR 评审者将可以像往常一样合并，无论是使用网页 UI 中的按钮还是使用命令行命令。如果推送仅发送 GitHub 已知且已在受保护分支上合并（无论是 fast-forward 合并还是其他）的提交，GitHub 允许在受保护分支上进行推送。
基本上，这意味着所有开发人员必须始终在自己的分支上进行所有开发，将这些分支推送到 Github，等待测试通过，然后才能从自己的本地仓库运行 git merge 和 git push。 GitHub 会识别提交 ID，并知道它们已被标记为已测试并已通过。
由于 MariaDB Server 的所有开发人员都已经习惯在独立分支上进行所有开发，并且只在最后一步才合并到主分支，因此使用受保护分支不需要任何人真正改变他们的基本工作流程。此外，没有人必须使用 GitHub 的网页 UI。所有提交 ID 和测试状态检测都在 GitHub 后端进行。它在 git push 时同样很好地进行门控，并在文本中打印出推送是否被接受的响应，因此命令行体验就像人们期望的那样好。
Travis CI 测试必须通过
除了我们的主要构建和测试系统 Buildbot 之外，项目源代码仓库中还定义了一个 .travis.yml 文件，并且 Travis-CI.org 已被激活。Travis CI 测试有一些限制，最显著的是最长 50 分钟的持续时间，因此它不像 Buildbot 测试那样全面。从门控的角度来看，这不是问题。事实上，Travis CI 测试范围略小是件好事，因此它们不那么挑剔。这些测试不包含所有存在的测试，它们只运行 Ubuntu 14.04 构建环境，并且只在 amd64 架构上运行。
如果代码更改导致在 Travis CI 上可以看到的失败，它肯定不能被接受到主线分支中。稍后，我们可以开始提高标准，要求每个开发人员考虑更多环境和架构以及更全面的测试。但对于门控的第一个版本来说，Travis CI 是完美的。
Travis CI 还有一个好处是，核心开发人员群体之外的任何人都可以轻松复制测试并在提交给 MariaDB 评审之前在 Travis CI 上测试自己的代码。对于 Github 上的任何 MariaDB/server 分支，Travis CI 都是免费使用的。
那么我们在等什么呢？
只剩下两个问题。首先，测试套件首先需要能够通过。如果代码库已经损坏，我们就无法激活门控。开发人员将被迫 100% 地专注于测试套件错误修复，许多人认为这是无趣的工作，特别是当是他们之前的某个人破坏了测试套件时。幸运的是，这是一次性的事情，拥有自动门控将确保这种情况不会再次发生。
其次，Travis CI 本身存在一些随机的失败，这些失败有点过于常见。Travis CI 实际上区分了错误（意味着测试标记了错误）和失败（源于 Travis CI 无法运行整个测试套件，例如由于网络错误或无响应的测试运行程序）。目前的失败似乎有点过于频繁，希望可以通过改进 Travis CI 平台来修复。
如果偶尔有一项作业失败，这没多大关系。开发人员不会花费太多时间查看错误消息并在该特定作业上按“重新启动”。
但如果误报过于频繁，那么真正的开发就会停滞不前，因为开发人员只会对着测试运行系统束手无策。
我们需要在 MariaDB 测试套件本身和 .travis.yml 定义文件上做更多工作，以获得一个可靠工作且误报率低于 1% 的系统。
这也是对 MariaDB 开发感兴趣的人阅读 Travis-CI.org 文档的好时机。它是一个出色的服务，被 github.com/MariaDB 上的多个仓库以及我们认识的许多公司用于使用 Travis CI 商业版持续测试他们的私有仓库。希望我们能尽快在 GitHub 和 Travis CI 集成方面取得进展，并激活受保护分支。