谷歌的多代码库开发

通常，由于存在外部依赖，复杂的软件项目会跨多个代码库。谷歌 WebRTC 项目的工程师 Patrik Höglund解释说，这本身就是一项挑战。他还描述了谷歌在开发像 Chrome 那样使用了若干第三方库的软件时采用的方法。

管理多代码库的复杂性源于跟踪外部依赖变化的必要性，尤其当它们的代码库快速变化的时候。在这种情况下，不能只是简单地跳过外部依赖更新，因为这会错过重要的补丁和新特性。另一方面，如果不经常更新外部库，那么就会面临这样的风险，累积的变化破坏了应用程序，需要很大的代价才能跟上所有的变化。

在谷歌，引入新的依赖版本称为“滚动（rolling）”。滚动是一个过程，需要修改 Chrome 的代码来适应任何新的 API，而这反过来会破坏 Chrome 的测试套件。当然，这种破坏直到运行整个测试套件时才能知道，那太晚了。为了避免破坏 Chrome 测试套件，开发人员使用专用的“机器人（bots）”（持续构建 / 测试机器）来检测滚动依赖可能引发的任何问题。

这样的机器人称为“FYI 机器人”。它们不会使用特定依赖的固定版本，即 WebRTC，而是使用 WebRTC HEAD 来代替。运行机器人可以得出下面任意一种结果：

• 机器人运行成功（绿色）：这意味着新的滚动很可能可以顺利进行。
• 机器人编译失败：这意味着必须修改 Chrome 的代码来适应一些新的 API。
• 机器人测试失败（红色）：这意味着存在一些语义变化或者新发现的 Bug 需要处理。

为了使这个过程运转的更顺畅，谷歌开发人员新增了一种策略，用于减少 FYI 机器人构件遭破坏的机会。机器人遭破坏会产生意想不到的结果，直到 Chrome 的代码修改完成，可以适应新的 API 了，那些机器人才会返回有意义的信息，而这要持续几天的时间。为了解决这个问题，开发人员开始遵循“ API 基本指令（API Prime Directive）”原则，确保在改进组件时不破坏现有的客户端。一种实现方式是，不删除任何现有的 API，而只是简单地增加所需的新 API。比如，我们有一个方法签名：

  
class WebRtcAmplifier {
 ...
 int SetOutputVolume(float volume);
}

让我们考虑代码需要变成下面这样情况：

  
class WebRtcAmplifier {
 ...
 int SetOutputVolume(float volume, bool allow_eleven1);
}

为了不破坏任何客户端，我们使用下面的 API：

  
class WebRtcAmplifier {
 ...
 int SetOutputVolume(float volume);
 int SetOutputVolume(float volume, bool allow_eleven);
}

借助这种策略，谷歌开发人员可以确保他们的机器人总是绿色的，如果它们在任何时候变成红色的，那么他们就知道更新应该回滚。

查看英文原文： Multi-repository Development at Google