谷歌的多代碼庫開發

英文原文：Multi-repository Development at Google

通常，由于存在外部依賴，復雜的軟件項目會跨多個代碼庫。谷歌 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);
}

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