iOS系統下的持續集成實踐

　　我們遇見的問題：

　　客戶端項目總是希望可以更快的拿出一個可用的版本，盡早的讓內部的同學試用這個新的客戶端，盡早的收集意見，盡早的修復問題，優化設計;同樣開發的同學在代碼修改的過程中也希望能夠更快的收到反饋。這就要求客戶端的測試能夠更快捷的響應，盡快的回歸新版本，及時的反饋問題，盡早的發出穩定的新版本來提供內測。因此客戶端的測試就產生了這些需求：

　　<!--[if !supportLists]-->1) <!--[endif]-->開發提交代碼之后盡可能快的發現和反饋問題;

　　<!--[if !supportLists]-->2) <!--[endif]-->更快的進行功能回歸，保證開發的修改不會對已有功能產生影響;

　　<!--[if !supportLists]-->3) <!--[endif]-->盡快的提供一個穩定版本用于內測，以方便更好的提升產品質量;

　　從上面的需求上來看，就出現了一個迭代，發布一個新版本內測帶來了使用者的反饋和建議，于是開發修改了代碼以提升質量，于是又發布了一個新版本提供內測，新版本又會帶啦新的建議和反饋，如此迭代著前進，于是項目質量越來越好，用戶體驗也越來越好，很美好的一個事情;

　　但是往往現實比較骨感，這樣的一個迭代節奏一旦被打破了，那么帶來的往往是一種災難，不停的發布新版本，結果問題越來越多，內測用戶越來越少，整個項目組的人反而越來越累;

　　為了避免這樣的問題發生，不讓一些壞的味道破壞項目的節奏，讓整個項目更好的運轉就需要滿足上面的這些需求，同時盡量讓這些需求做到更加的自動，減少人的參與，本地生活業務線就在這樣的情況下開始了嘗試，去試著形成自己的節奏，解決自己的問題。

　　在這里說一說本地生活業務線的持續集成，和大家一起沿著這條路走走：

　　最初的分析：

　　首先想到的第一點，自動化。那么如何來做iOS客戶端的自動化測試呢?話說站在巨人的肩膀上，對于本地生活也是如此;于是開始對于自動化的框架進行選型，調研了不少的團隊，最終選擇使用athrun來做本地生活的自動化框架，原因也很簡單：第一，就團隊和個人來說，對于Java比較熟悉，雖然使用Javascript可以帶來錄制的便利，但是從長遠來看使用athrun對于團隊來說效率應該更高，學習成本也會比較低;第二，使用athrun很好的和JUnit集成起來，而JUnit的框架比較成熟，帶來斷言，日志等便利，可以豐富腳本運行時的日志，便于后期對于結果的分析;當然了，最主要的原因還是因為第一條，學習成本比較低，對于語言比較熟悉;

　　繼續深入下去，發現athrun在運行的時候需要提供一個app文件，如此帶來了一個新的問題：如何保證我測試的這個app包是最新的，怎么更快的獲取這個包，怎么減少人工干預?一般測試過程中工程都是通過Xcode來進行build的，那么是否存在另外的方式來解決這個問題呢?經過學習之后發現Xcode提供了命令行工具，通過這個工具就可以使用命令行來build工程，自動打包;那么是不是可以通過一段shell命令完成這個工作呢?于是寫了一個shell腳本來進行項目的build工作，在每次執行自動化腳本之前build一下最新的包，那么自動化腳本的執行的app就是最新的了;

　　好的，自動化的工作由此展開，然后新的問題又出現了，項目進行到后期開發提交的代碼的環境設置往往是預發布環境，而自動化運行的環境是測試環境，更悲劇的是發布到內測的版本的環境是線上環境，如此三個環境的切換開始了，懶人總是希望不要將這些繁瑣的事情讓自己來完成，于是想盡辦法來偷懶，結果就選擇了一個最笨的方式，通過shell來做環境切換;對于不同的環境建立不同的版本，在版本build之前先將環境做修改以滿足不同的需求;

　　要發布第一個內測版本的包了，還是蠻開心的，丑媳婦終于要見公婆了，卻被告知啥要提交一個ipa包，對于我這樣一個之前從沒有使過蘋果的低端用戶簡直就是一個基礎掃盲，被發配回去重新研究生成ipa包，開始的時候使用Xcode來生成ipa包，每次上傳之前先自己生成一下，然后再上傳。但是這對于一個懶人是怎樣的一種折磨啊，于是去想辦法偷懶，發現jenkins中提供了一個Xcode Plugin的插件，這個插件不但可以進行項目的build還可以生成ipa包，好吧，前面的功夫白費了，棄暗投明唄!

　　這三個多月以來一直在解決著自己的問題，在這個過程中遇見了很多問題，也解決了很多的問題，通過解決這些問題對于最初的三個需求有了更深的思考，于是隨手拿起筆涂鴉一下。

　　進一步思考：

　　目前本地生活的iOS客戶端已經有2個在AppStore上發布，在這兩個項目中對于上面的部分都進行了實踐，梳理出了如下的流程：

　　這個過程中形成了一套適合自己的持續集成的過程，在開發提交代碼之前對于代碼進行靜態掃描，將除去第三方庫以外的問題修復，之后提交的代碼將會被Xcode Plugin進行build，在build過程中將將會對于不同的需求構建不同的包，在其中用于自動化回歸的包上執行自動化腳本，對于穩定版本(自動化測試通過)的正式ipa包上傳至內測版本下載服務器;其主要的步驟包括以下部分：

　　<!--[if !supportLists]-->1) <!--[endif]-->更新最新代碼;

　　<!--[if !supportLists]-->2) <!--[endif]-->靜態分析;對于代碼進行靜態檢查，Xcode使用的靜態檢查工具為Clang Static Analyze，該工具可以監測出代碼中潛在的內存泄露、使用未賦值變量、變量申明后未使用等問題，如果發現了相應的問題，通知開發進行修復(目前這一步驟沒有通過自動的方式來實現，還是通過和開發的規約來保證，再之后會將這部分自動化實現);

　　<!--[if !supportLists]-->3) <!--[endif]-->版本構建;針對不同的需求構建不同的版本，這步是通過Xcode Plugin來實現，Xcode Plugin使用的仍然是xcodebuild命令行，在這一步驟中需要提供環境切換的腳本，而不同的項目可能開發實現環境切換的方式都不同，因此這里經常是讓人很抓狂的地方，需要和開發進行進一步的溝通共同確定環境切換的規約。在構建之后需要對于這些修改進行還原操作，不要遺漏修改的代碼還原;

原文轉自：http://www.anti-gravitydesign.com