[[330177]]

最近，我們在 Gusto 創(chuàng)下了一個新紀錄：6 分 29 秒。

這是我們?yōu)?Gusto 最大的一個應用程序，一個 Rails 單體程序運行測試套件所花費的時間。6 分 29 秒是公司的持續(xù)集成（CI）流水線啟用以來的最快紀錄。上一次 CI 套件跑出這樣的成績，公司的規(guī)模還很小，而現(xiàn)在我們共有全球數(shù)百名工程師在使用這個 Rails 單體應用，為全美 1% 的小型企業(yè)提供支持。

對 Gusto 而言，高速 CI 流水線并不只是做做樣子，我們把它視為一種競爭優(yōu)勢，代碼部署越快，那么客戶的業(yè)務開展也會越快。隨著 CI 速度的提升，工程師的生產(chǎn)率也在提高，CI 時間每縮短一分鐘，Gusto 每位工程師每周可增加 2％的拉取請求。

我們的目標很簡單，希望讓測試套件的速度成為一個參數(shù)的函數(shù)，這個參數(shù)就是：我們愿意花多少錢？將基礎架構(gòu)簡化到這個層面后，就更容易做成本效益分析，例如如果想要將構(gòu)建速度從 7 分鐘提升到 5 分鐘，那么需要花費 1 美元。

這篇文章介紹了我們是怎樣加快測試套件速度的，其中涉及一個 Rails 單體程序和一個主要用 React 編寫的 JavaScript 單頁應用程序（SPA），這些經(jīng)驗適用于所有速度較慢的測試套件。

我的同事 Kent 說，構(gòu)建軟件有 3 個步驟：

• 讓它跑起來（Make it work）
• 讓它走上正軌（Make it right）
• 讓它跑得更快（Make it fast）

“讓它跑起來”指的是做出不會隨便崩潰的軟件。在這一步代碼可能晦澀難懂，但足以為客戶提供價值，并且通過了測試，讓我們能信任它。沒有測試，就很難判斷“它能行嗎？”

“讓它走上正軌”指的是要讓代碼可維護，且易于更改。代碼不僅能在計算機上運行，更要讓人容易理解。新來的工程師可以輕松向代碼添加功能，代碼中的缺陷也應該很容易隔離和糾正。

“讓它跑得更快”指的是要提升軟件性能。為什么它會是最后一步呢？對于像 Gusto 這樣的金融科技公司來說，如果只關注速度卻無視質(zhì)量，那么我們的客戶和我們自己就離破產(chǎn)不遠了。并非每段代碼都需要優(yōu)異的性能，如果一段代碼每天可能只執(zhí)行一次，那么就算它有”高性能”水平，卻難以閱讀和理解，那也是一段失敗的代碼。

我們把這套原則應用在 CI 套件的提速優(yōu)化過程中。

1. 讓它跑起來

消除不可靠測試

首先需要做的事情是消除測試套件中的不可靠測試（test flakes）。不可靠測試（flaky test）指的是結(jié)果不確定的測試，它有時會通過，有時會失敗。速度飛快但不可靠的測試套件并不能讓你確信代碼可以正常運行，這只是在拋硬幣賭運氣而已。

為了讓一個規(guī)模龐大的工程團隊消除不可靠測試，我們采用并執(zhí)行了以下政策：

在 master 分支上所有失敗的測試都將視為不可靠的。這些測試將標記為已跳過（skipped）。負責不可靠測試的團隊可以在空閑時修復它們并取消跳過標記。

這個做法不僅能讓測試套件一直亮綠燈，同時也讓各個團隊決定何時編寫更多確定性測試。他們可以立刻開始編寫，也可以選擇等到再次處理這個功能時再行動。這種方法減少了一個團隊的不確定測試給其他團隊帶來的損害。

當然，這種方法也存在質(zhì)疑，“如果我們跳過了一項重要的測試該怎么辦？”是最常見的問題。沒錯，這個問題很重要，但我們需要搞清楚問題的背景。一個測試之所以會被標記為已跳過，是因為它會隨機失敗，首先要考慮的是我們對這個測試和功能到底有多大的信心。很多時候，測試會出現(xiàn)不可靠情況是因為生產(chǎn)環(huán)境中的確存在錯誤！

通過這種方式，我們在主分支上的構(gòu)建綠燈率從約 75％增至 98％！

2. 讓它走上正軌

回到默認狀態(tài)

隨著時間的流逝，我們逐漸偏離了運行 RSpec 測試的默認路徑。遵守默認值是很難的。下面是 RSpec 測試的一些默認值：

在各個測試用例之間重置狀態(tài)。這樣可以確保測試是可重復的、確定性的，并且不會相互依賴。

測試執(zhí)行是隨機的。這樣可以確保測試之間不存在相互依賴，幫助避免測試污染。

測試文件使用 Rails 自動加載器。這意味著我們僅加載應用程序所需的部分，而不是程序整體，可以幫助避免不完整的測試設置。

重新采用這些默認值的過程并不輕松。確保每個測試用例都重置其狀態(tài)（數(shù)據(jù)庫、Redis 值、緩存等），都會帶來新的不可靠測試。根據(jù)其性質(zhì)，我們可以修復更改或?qū)⒅罢５臏y試標記為不可靠。

我們慢慢重新引入了 RSpec 默認值，這為測試提速奠定了基礎。

3. 讓它跑得更快

引入測試時間上限

我們的測試是不平衡的。有些測試文件只需幾毫秒就能執(zhí)行完畢，還有些則需要花費數(shù)十分鐘時間。耗時幾分鐘的測試是集成測試，涉及我們應用程序中最重要的一些流程。我們希望這些測試的速度能更快，但并不想移除它們。

因為測試套件是分布在多個節(jié)點上并行執(zhí)行的，所以很快就遇到了測試提速的瓶頸。

我們的測試套件速度取決于最慢的測試文件，因此實施了一項新政策：

任何測試文件的執(zhí)行時間都不能超過 2 分鐘。

這個門檻是憑空拉出來的，但似乎很實用。我們只有 40 多個耗時超過 2 分鐘的文件。

確定界限之后，我們開始處理速度緩慢的測試，試圖讓它們通過新的門檻，之前 40 個文件的時間都降到了閾值以下。之后，每個團隊都有責任確保其測試文件的執(zhí)行時間不超過 2 分鐘，而執(zhí)行時間超過 2 分鐘的測試文件會被標記為已跳過。

根據(jù)最壞情況來平衡測試

現(xiàn)在我們有了一個可靠的測試套件，只是速度很慢，它可以按任何順序執(zhí)行測試，但是將測試分配給節(jié)點的方法是隨機的。有些節(jié)點只需幾秒鐘就完成了，而另一些節(jié)點則需要數(shù)十分鐘。我們怎樣才能讓它們平衡呢？

我們面臨的最后一個問題是測試平衡。我們在這一步評估了兩種解決方案：

1. 開發(fā)一個隊列，以在節(jié)點準備就緒后為其輸入測試用例。雖然這種方案原理上沒問題，但 RSpec 需要對框架做大幅更新才能兼容這種方案。此外，它在所有各不相同的并行作業(yè)之間引入了共享狀態(tài)。
2. 在一次 CI 流程開始時在一個數(shù)據(jù)庫中記錄測試時間，將測試分為不同的桶，讓所有分組都有相同的長度。

我們采用了記錄與分桶的方法將測試分配到各個節(jié)點上，因為它非常適合 knapsack（https://docs.knapsackpro.com/ruby/knapsack）。測試運行期間，這種方法也不會在許多不同的并行作業(yè)之間共享狀態(tài)。這是很重要的，因為一個共享隊列可能有數(shù)百個節(jié)點，每個節(jié)點每秒為一個構(gòu)建可以請求數(shù)千次工作。

我們建立了一個 MySQL 實例來記錄所有文件的測試時間。在每次 CI 流程開始時，它會根據(jù)每個測試文件的第 99 個百分位時間生成一個 knapsack 文件。在每次 CI 流程結(jié)束時，它將上傳新的結(jié)果。

為什么是第 99 個百分位？由于我們在共享硬件（AWS）上運行 CI，因此無法控制基礎架構(gòu)，各個測試文件的測試時間會大相徑庭。我們無法將這些波動與使用的 EC2 實例類型，或者其他任何可以衡量的參數(shù)關聯(lián)起來。

我們沒有進一步完善構(gòu)建基礎架構(gòu)，而是讓系統(tǒng)具備了彈性。我們使用第 99 個百分位來組織測試，從而保證了測試的性能表現(xiàn)有一個下限，而不是在獲得較好的平均性能時卻存在明顯偏低的個例。即便底層硬件發(fā)生變化或基礎架構(gòu)層出現(xiàn)故障，CI 管道依舊能保障可預期的性能水平。

這套策略實施之后，我們就有了一個自平衡的系統(tǒng)。測試越多，系統(tǒng)也就越平衡。如果某些測試隨著時間的推移變慢，則測試桶也會隨之調(diào)整平衡狀態(tài)。

提升并行度

現(xiàn)在到了有意思的地方：讓測試速度真的變快。

這里的主要做法是增加并行度。項目開始以來，我們已經(jīng)從 40 個并行作業(yè)增加到了 130 個。這稍稍增加了成本，但大幅提升了 CI 的運行速度。在 Gusto，我們使用 Buildkite 作為 CI 基礎架構(gòu)，但這種并行化的理念適用于所有主流 CI 產(chǎn)品。

雖然我們將并行度提高到了 3 倍以上，但 CI 費用卻沒有隨之線性增長。為什么？因為我們更好地利用了已有的 CPU 時間，通過在各個節(jié)點之間平衡作業(yè)，總 CPU 時間并沒有變化，但是實際運行時間大幅縮短了。

4. 總結(jié)

在過去幾個月中，我們在一點點讓 Gusto 主要應用程序的 CI 管道變得更堅實可靠，而且速度更快。

這種改進依舊是一項日常工作。在出現(xiàn)不可靠測試時我們還是會跳過它們，或者尋找新的優(yōu)化策略來加快構(gòu)建速度。無論你們現(xiàn)在使用的是什么技術，我們都希望這篇文章可以為你們的團隊提供一個路線圖參考，幫助改進你們的 CI 管道和軟件發(fā)布架構(gòu)。