iOS 開發在經過這幾年的野蠻生長之后，慢慢地趨于穩定。無論開發語言是 Objective-C 還是 Swift,工程類型是 Hybird 還是原生，開發思想是 OOP 還是函數式，隨著項目逐漸變大都在面臨相同的問題: 測試、發布等重復性工作占了很大一部分時間，回歸成本越來越高。持續集成不可避免地被提上了日程。
本文主要闡述 iOS 下的持續集成，以目標、內容、流程、工具入手，希望可以為大家描繪一幅 iOS 持續集成的藍圖。這可能不是一篇可以讓你 Step by Step 跟著做的文章，但愿可以在你腦海中建立相關概念，以便在實操時走對方向。
我們會在后面幾篇內容中，詳細闡述 是什么 和 如何做 。
對于我們來說，減少重復工作、提升團隊效率。 對于公司來說，省錢！
狹義上持續集成指早集成早測試盡早早發現問題早修復，并輔以一些自動化的手段，其目標是減少修復的成本。通過其目的，我們可以發現，其實通過自動化減少重復工作和通過早發現問題降低成本是持續集成的核心理念。因此，我把自動化 Code Review 也放到這里講。
iOS 下的持續集成內容包括自動化 Code Reivew、自動化單元測試、自動化打包和自動化分發。自動化 Code Review 保證團隊遵守代碼規范，在編碼階段減少 BUG 的產生。在人員流動較大的公司里，用同一套代碼規范，也可以保證項目交接更流暢。自動化單元測試在集成階段檢測出 BUG ,以減少回歸成本。自動化打包和自動化分發則是減少重復勞動，畢，工程師的時間就是金錢啊。
顧名思義，自動化 Code Review 既采用自動化的手段，對團隊成員得代碼進行 Review，以保證代碼質量。從現實角度來說，自動化的 Code Review 更多地是對代碼進行靜態分析，通過掃描代碼并對比制定的規則，產出所需要的結果。這個所需要的結果，可以是工程總體的量化的質量報告，也可以是顯示在 Xcode 中的一條警告??。這取決于用戶是什么角色。
在實際實踐中，一般會有兩種角色會關注這份結果 -- 工程師和管理層。工程師需要在開發的過程中及時了解代碼錯誤，以便及時糾正。管理層需要了解工程的總體代碼質量，以掌握項目的相關風險。同時，也可以作為工程師績效的依據之一。
要完成這一塊內容，我們需要這些工具:
通過這三者協作，我們可以實現以下流程:
工程師通過 `Git Commit` 提交代碼 → Web Hook 觸發 `Jenkins` 構建 → `OCLint` 掃描代碼生成PMD格式報告 → `Sonar-runner` 讀取報告并展現到 `SonarQube`。 關于 Code Review 需要指出的是，自動化工具是有局限性的。其無法分析出較為"智能"的規則。比如說下面這條
4.7 方法名以小寫字母動詞作為開頭
還有下面這種代碼，盡管含有多個容易造成閃退的 BUG,也是可以順利逃過分析器的眼睛的
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 相結合。
自動化地執行單元測試，在測試失敗的情況下中斷集成，并通知相關人員，就是這一塊工作的內容。
為此，我們需要如下的工具:
我們可以實現以下的流程:
`Git Merge` → Web Hook 觸發 `Jenkins` 構建 → xctool 執行單元測試 → 如果失敗則發郵件給相關人員。 當然，如果你公司的項目托管在 GitHub 上，業界有兩個非常的 Jenkins 替代產品 travis-ci 和 circle-ci。他們對 GitHub 的支持完美，且對開源項目是免費的。私有項目則需要付費試用。
在單元測試這一塊，高的成本還是寫單元測試的時間成本。腦洞大開地說，如果能實現一款工具，可以自動地為業務代碼生成測試代碼，那才是生產力的大大提升。
一次完整的打包，需要經歷配置證書、切換環境、調整參數(構建版本號等)、Archive、導出。 根據工程的復雜程度，以上過程快則五分鐘，慢則半小時。當需要頻繁發版的情況下，浪費了工程師非常多的時間。
我們其實可以利用一些工具來實現這樣的一個流程:
Git Merge 到 Master（通常這意味著一個 Release）→ 觸發 Jenkins 構建生成 ipa → 自動化分發。
自動分發包含以下工作：
我們可以分別配置相關的腳本，來實現測試的分發，和發布等。
要實現這樣的流程，我們需要這些工具:
Fastlane 是由一個個小組件組成的工具，功能包括上傳截圖到 iTunes Connect,創建 provisioning file, 管理 TestFlight 的測試員，分發等。這個工具幾乎可以用命令行來實現打包上傳分發相關的所有功能，并且越來越有成為默認的業界持續集成標準工具的樣子。就像 CocoaPods 在依賴管理方面一樣。
持續集成，可以看做是通過版本控制系統、CI平臺(如Jenkins)和相關工具鏈來完成一套工作流，以減少團隊重復性工作，并保證軟件可以不停地迭代而不出太大的差錯。iOS 下的持續集成大體就是上述幾塊內容，我們在實現的過程中遇到了不少坑，后面的文章分塊詳細講。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
