[譯]如何快速穩定地構建iOS應用

njkf2843 8年前發布 | 15K 次閱讀 iOS開發移動開發

Voyager項目是為了開發LinkedIn新的旗艦級手機應用，去年年初，我們開始在項目中實踐3x3哲學：

一天發布三次，從代碼提交到用戶可以使用，不超過三小時。

雖然我們不能每三個小時向App Store發布一次，但我們每天可以多次構建員工使用的企業產品。“3x3”聽起來很快很容易，但說起來容易做起來難。三小時一發布的節奏，讓我們沒有時間做手工測試，所我們需要一個通道：

1.從代碼提交到產品發布，每個環節都完全自動化

2.可靠性要好，甚至要高于手工測試

3.速度足夠快，能夠適應我們三個小時的窗口期

4.穩定性，確保每個合法提交都會被發布

今年年初的時候，Drew Hannay在他的博客，3x3：加速手機應用的發布中簡要介紹了手機應用3x3哲學。圍繞快速和穩定構造，我們將深入探索3x3在iOS應用開發中的應用。

第一部分：速度

為了獲得一個從代碼提交到發布小于三小時的通道，我們通過重構Swift代碼，加速編譯速度，加速我們的UI測試框架，構造和測試并行等手段，以優化我們的構造通道。

加速代碼編譯

我們選擇Swift做為新的旗艦級應用Voyager的主力開發語言，從最早的1.0到2.0隨著Swift的不斷升級，我們的項目也在不斷演變。

在Voyager項目早期，我們非常享受Swift的易用和先進的功能，但漫長的編譯時間長長令我們沮喪。隨著起來越多的代碼提交到我們的iOS代碼庫（每天大約60次提交），我們發現即便只有少數文件發生變更，編譯時間也呈指數增長，從數秒到30分鐘左右。更糟糕的是發布構建時間比調試構建時間更長，通常需要2個小時。秉承“測試要與開發同步”的原則，我們要另外再花兩個半小時來寫150個KIF測試。結果，我們需要花四個半小時完成從提交到發布的過程！

為了緩解開發者的挫敗感，我們通過Apple開發者社區，Apple開發者論壇和公司合作伙伴關系努力與Apple工程師溝通。并就如何縮短我們的構建時間，獲得了很多寶貴的反饋意見。 Jacek Suliga負責一個主要代碼庫的重構，將我們的工程分成不同的子項目和模塊，用顯式引用取代隱式引用。這使得調試構建時間幾乎縮短了一半，發布構建時間從原來的2小時縮短到35分鐘，從提交到發布時間縮短到3個小時。對于本地開發，我們為每個iOS開發人員購置了一臺Mac Pro，以減少調試構建時間。

UI測試框架優化

構建時間優化之后，UI測試時間成為瓶頸。Jacek在 UI自動化：保持實用和穩定一文中介紹了我們如何優化開源項目KIF，讓它可以5到10倍地提速。這大大縮短了測試時間，測試運行時間縮短了80%，只需要大概20分鐘時間。然而，測試越來越多，一個月內增長了四倍，測試時間增長到80分鐘，總時間增長到2個小時。

在對編譯和UI測試框架做了優化之后，我們認為只有技術創新才能顯著解決從提交到發布的時間問題，我們將重點放到了：分布式構建和測試。

分布式構建和測試

我們與基礎設施團隊密切合作，為iOS和Android提供分布式編譯和測試支持。當我們將所有構建和測試任務分發到10臺機器上，唯一的瓶頸就變成了發布構建時間，加上一些工具開銷，需要35分鐘完成。提交到發布的總時間下降到45分鐘。使用更多的機器可以進一步提高構建時間，但是也會引入一些可靠性問題，我會在穩定性部分闡述

第二部分：穩定性

在我們的構建通道中，從提交到發布，有兩個關鍵組件會影響整體穩定性：測試系統的穩定性和構建工具的穩定性。

1. 測試系統穩定性

在我以前的博客：測試穩定性 - 我們如何讓UI測試變得穩定，我討論了我們如何構建穩定的測試環境。主是是穩定的測試環境，從測試框架中移除不可預測的因素，凈化我們的測試組件。請重溫一下那篇博客，關于我們如何讓我們的測試基礎設施變得穩定的細節。

2. 工具穩定性

2.1 硬件穩定性

我們通過cfengine集中管理我們的機器池，現在我們有兩類Apple硬件：

Mac Mini (2012年版)

①處理器 2.6GHz Quad-Core Intel Core i7

②內存 16GB 1600 MHz DDR3

③存儲 1TB HDD

④Intel HD 顯卡

Mac Mini (2014年版)

①處理器 3.0GHz Dual-Core Intel Core i7

②內存 16GB 1600MHz LPDDR3 SDRAM

③存儲 512GB PCIe-based Flash Storage

④Intel Iris 顯卡

有一次，我們看到建構池中出現內存問題，有10%的機器活動內存小于100MB，大量使用交換分區。當檢查這些內存不夠用的機器時，我們發現在后臺有20多個長期運行的xcodebuild進程。我們意識到這是此前掛起的xcodebuild進程所致。

為了解決這個問題，我們采取了以下行動：

1. 添加重試邏輯，在運行新的任務前，清除所有掛起的xcodebuild進程。

2. 對有可能導致內存溢出的服務每天定期重啟。

3. 對交換分區使用較多的機器設置自動報警。

2.2 Mac 系統構建環境穩定性

除了內存問題，我們偶爾也會發現機器上有運行iOS模擬器問題，這些問題影響了整體穩定性。一旦機器上出現模擬器問題，如果不正確處理，它會影響這臺機器接下來的所有構建任務。我們曾經付出巨大的努力來解決模擬器問題（參見：企業級iOS持續集成管理），但當我們嘗試解決這個問題時，發現還不如先前的效果，因為模擬器工具并不在我們的控制之中。

幸運的是，我們發現重啟可以解決絕大部分模擬器問題。我們啟動了一個叫PoolGuardian的項目，用來監控所有構建機器，并且定期檢查是否有機器出現模擬器問題，如果發現有問題，它會重啟這臺機器，并且在重新使用這臺機器前會做健康檢查。

2.3 并行測試穩定性

分布式測試看起來很有前景，因為它確實解決了我們的速度難題，但是當我們遇到一些可靠性問題時，我們意識到它是一把雙刃劍。

在我們的Mac系統工具鏈環境中，我們遇到一些Apple開發者工具鏈問題，包括間歇性編譯崩潰，模擬器崩潰，模擬器重復性錯誤，和環境錯誤問題。總之，每天機器的穩定性大概在95%左右。看起來好像還不錯，但是在分布式測試中，只有所有子任務全部通過，一個構建才能完成，確切一點說，10個子任務要全部通過。所以每加一個節點，總體可靠性下降到原來的95%，隨著結點數的增加，整體可靠性呈指數下降。如果使用10個結點，工具鏈的可靠性下降到95%10 ≈ 60%。

為了改善上面提到的工具鏈可靠性問題，我們優化了我們的構建池，使用種種手段讓我們的 Max OS X更加可靠。通過這些努力，工具鏈的穩定性從95%提高到略高于98%。加上其他結點，穩定性仍然有98%10 = 82%。這遠遠沒有達到我們的預期—99%的可靠性。但是解決x10 = 99%需要 x = 99.9%，這就需要99.9%的機器可靠性，這需要更多的資源和精力。

同時，我們試圖跳出這個怪圈，我們希望在高可靠性的同時，我們的構建通道可以快速完成提交到發布過程。然后我們有了一個突破：如果我們把所有任務都放到一個測試結點，同時使用多個模擬器跑測試會怎么樣？基于這個想法產生了Hydra項目，Hydra的總體目標是：

1. 在一臺服務器上使用多個模擬器并行跑測試，讓構建時間提高5到10倍。

2. 啟用不同模擬器之間的交互測試（iOS與iOS, Android與Android ，iOS與Android）

在這篇博客中，我只涉及第一個目標。下圖是多模擬器測試架構。

當一個提交發生后，測試運行器會構建應用并啟動5個模擬器用來組成一個模擬器設備池。構建完成后，測試運行器將查詢測試集群，獲取一個測試類列表。根據測試用例的數目，測試類會動態分配到20個單元中，并形成一個測試隊列。一旦初始化階段完成，設備池會不斷地獲取測試任務并運行。同時設備池有一個健康監測進程保證設備池的健康運行。一個測試任務結束后，測試成果和測試報告會被收集并上傳到持續集成工具，等待下一個發布周期。

你可能會問，為什么我們選擇運行5個模擬器，這是因為OS對每個shell會話的進程有個默認限制，在Mac Mini上是709。每個模擬器會產生大約70個進程。當我們添加300個MacOS系統進程，我們同時只需啟動5到6個模擬器。我們曾經試圖取消shell進程限制數，但是當超過700個進程時，OS環境會變得很脆弱。所以，權衡擴展性和可靠性，我們選擇5個模擬器。

有了Hydra的幫助，我們的構建穩定性從最初的0提高到今天的90%，而且我們還在不斷的優化它。下圖是一個示例，我們會以我們的方式開源這個項目，敬請關注！