- iOS 持續整合 – 開篇
- iOS 持續整合 – 自動化 Code Review
- [iOS 持續整合 – 自動化單元測試]
- [iOS 持續整合 – 自動化打包與分發]
前言
iOS 開發在經過這幾年的野蠻生長之後，慢慢地趨於穩定。無論開發語言是 Objective-C 還是 Swift,工程型別是 Hybird 還是原生，開發思想是 OOP 還是函式式，隨著專案逐漸變大都在面臨相同的問題: 測試、釋出等重複性工作佔了很大一部分時間，迴歸成本越來越高。持續整合不可避免地被提上了日程。
本文主要闡述 iOS 下的持續整合，以目標、內容、流程、工具入手，希望可以為大家描繪一幅 iOS 持續整合的藍圖。這可能不是一篇可以讓你 Step by Step 跟著做的文章，但願可以在你腦海中建立相關概念，以便在實操時走對方向。
我們會在後面幾篇內容中，詳細闡述 是什麼 和 如何做 。
目標
對於我們來說，減少重複工作、提升團隊效率。 對於公司來說，省錢！
狹義上持續整合指早整合早測試儘早早發現問題早修復，並輔以一些自動化的手段，其目標是減少修復的成本。通過其目的，我們可以發現，其實通過自動化減少重複工作和通過早發現問題降低成本是持續整合的核心理念。因此，我把自動化 Code Review 也放到這裡講。
內容
iOS 下的持續整合內容包括自動化 Code Reivew、自動化單元測試、自動化打包和自動化分發。自動化 Code Review 保證團隊遵守程式碼規範，在編碼階段減少 BUG 的產生。在人員流動較大的公司裡，用同一套程式碼規範，也可以保證專案交接更流暢。自動化單元測試在整合階段檢測出 BUG ,以減少迴歸成本。自動化打包和自動化分發則是減少重複勞動，畢竟，工程師的時間就是金錢啊。
自動化 Code Review
顧名思義，自動化 Code Review 既採用自動化的手段，對團隊成員得程式碼進行 Review，以保證程式碼質量。從現實角度來說，自動化的 Code Review 更多地是對程式碼進行靜態分析，通過掃描程式碼並對比制定的規則，產出所需要的結果。這個所需要的結果，可以是工程總體的量化的質量報告，也可以是顯示在 Xcode 中的一條警告⚠️。這取決於使用者是什麼角色。
在實際實踐中，一般會有兩種角色會關注這份結果 — 工程師和管理層。工程師需要在開發的過程中及時瞭解程式碼錯誤，以便及時糾正。管理層需要了解工程的總體程式碼質量，以掌握專案的相關風險。同時，也可以作為工程師績效的依據之一。
要完成這一塊內容，我們需要這些工具:
通過這三者協作，我們可以實現以下流程:
|
1 2 |
工程師通過 `Git Commit` 提交程式碼 → Web Hook 觸發 `Jenkins` 構建 → `OCLint` 掃描程式碼生成PMD格式報告 → `Sonar-runner` 讀取報告並展現到 `SonarQube`。 |
關於 Code Review 需要指出的是，自動化工具是有侷限性的。其無法分析出較為”智慧”的規則。比如說下面這條
4.7 方法名以小寫字母動詞作為開頭
還有下面這種程式碼，儘管含有多個容易造成閃退的 BUG,也是可以順利逃過分析器的眼睛的
|
1 2 3 4 5 6 |
if result?.bindPhone == "true" { let range = (result?.loginId?.startIndex.advancedBy(3))!...(result?.loginId?.endIndex.advancedBy(-5))! let phoneNumber: String? = result?.loginId?.stringByReplacingCharactersInRange(range, withString: "****") self.phoneNumLabel.text = phoneNumber! } |
因此，想要達到 “保證程式碼質量” 的目的，還需要人工 Review 和自動化 Review 相結合。
自動化單元測試
自動化地執行單元測試，在測試失敗的情況下中斷整合，並通知相關人員，就是這一塊工作的內容。
為此，我們需要如下的工具:
我們可以實現以下的流程:
|
1 2 |
`Git Merge` → Web Hook 觸發 `Jenkins` 構建 → xctool 執行單元測試 → 如果失敗則發郵件給相關人員。 |
當然，如果你公司的專案託管在 GitHub 上，業界有兩個非常優秀的 Jenkins 替代產品 travis-ci 和 circle-ci。他們對 GitHub 的支援完美，且對開源專案是免費的。私有專案則需要付費試用。
在單元測試這一塊，最高的成本還是寫單元測試的時間成本。腦洞大開地說，如果能實現一款工具，可以自動地為業務程式碼生成測試程式碼，那才是生產力的大大提升。
自動化打包與分發
一次完整的打包，需要經歷配置證書、切換環境、調整引數(構建版本號等)、Archive、匯出。 根據工程的複雜程度，以上過程快則五分鐘，慢則半小時。當需要頻繁發版的情況下，浪費了工程師非常多的時間。
我們其實可以利用一些工具來實現這樣的一個流程:
Git Merge 到 Master（通常這意味著一個 Release）→ 觸發 Jenkins 構建生成 ipa → 自動化分發。
自動分發包含以下工作：
- 自動上傳 App Store
- 自動使用 TestFlight 分發
- 自動上傳到 蒲公英/Fir 等平臺
- 自動上傳到企業 App Store
我們可以分別配置相關的指令碼，來實現測試的分發，和釋出等。
要實現這樣的流程，我們需要這些工具:
Fastlane 是由一個個小元件組成的工具，功能包括上傳截圖到 iTunes Connect,建立 provisioning file, 管理 TestFlight 的測試員，分發等。這個工具幾乎可以用命令列來實現打包上傳分發相關的所有功能，並且越來越有成為預設的業界持續整合標準工具的樣子。就像 CocoaPods 在依賴管理方面一樣。
總結
持續整合，可以看做是通過版本控制系統、CI平臺(如Jenkins)和相關工具鏈來完成一套工作流，以減少團隊重複性工作，並保證軟體可以不停地迭代而不出太大的差錯。iOS 下的持續整合大體就是上述幾塊內容，我們在實現的過程中遇到了不少坑，後面的文章分塊詳細講。