iOS系統下的持續集成實踐(4)

　　目前客戶端和服務端的交互一般做法是通過http請求進行的，服務端處理之后將結果用json串進行返回，因此針對這樣的協議在框架工程中添加了對于http的封裝，通過這部分可以實現在對于服務端接口的測試，因此在同一個業務的自動化工程中可以進行UI自動化測試，同時也可以進行服務端的接口測試;

　　在這里的另一個問題是任何協調自動化驗證的版本和build出來的版本，目前是做了這樣一個約定，統一一個地方存儲構建之后的版本，build成功后將構建出來的新版本放置在這個約定位置，然后自動化腳本配置執行的app位置就是這個約定位置，從而保證自動化運行的app都是最新的成功版本，并且不需要通過人工的方式來進行同步;因此在build的步驟中加了一步在每次成功構建之后將構建的結果放置在這個指定位置：

　　然后在自動化腳本的配置中按照如下的方式指定運行的app位置：

　　自動化測試運行需要時間，如果每次在代碼提交之后都運行自動化測試驗證的話可能不一定合適，同時新版本的更新也不需要每天都更新幾次新版本，目前本地的新版本更新基本上一到兩天一次比較適合，因此設置自動化驗證Job的執行策略是每天定時執行一次;

　　關于更新ipa包：

　　到這里故事就走到要結束的部分了，構建了穩定的新版本之后的下一個任務就是把新版本發布內測，這個部分定義在自動化驗證的Job中，在自動化驗證的步驟之后增加一個新的步驟用于上傳ipa包，這一步需要內測版本下載服務器提供一個接口或者一種策略來支持ipa的上傳和更新，目前本地的內測版本下載服務器的這個功能還在開發中，因此ipa包的更新還是靠手工上傳;

　　下一步展望：

　　目前的這個方式不是最好的方式，那么如何把iOS的持續集成做的更好，下一步又該是怎么樣的呢?在這里說說自己的一點看法：

　　<!--[if !supportLists]-->1) <!--[endif]-->目前這一套的東西游離在kelude的框架之外，而看看Xcode Plugin這些的最終實現仍然是使用的Xcode的命令行工具，那么理論上這個就應該可以統一起來整合在我們自己的框架之下;

　　<!--[if !supportLists]-->2) <!--[endif]-->目前整個流程中缺少了單元測試的這部分內容，由于本地的業務目前單元測試實施的意義不大因此忽略了這部分內容，在之后客戶端形成自己業務SDK之后需要將這一部分補充上來;

　　<!--[if !supportLists]-->3) <!--[endif]-->目前代碼的靜態檢查主要還是依賴于和開發之間的約定，依賴于Xcode來進行，雖然jenkins提供了Clang Scan-Build Plugin插件進行集成，但是目前還沒有將這部分內容很好的集成進來，在之后需要對這部分進行補充，同時過濾第三方的問題，而把關注點集中在自己的項目上;

　　<!--[if !supportLists]-->4) <!--[endif]-->目前環境切換腳本，構建和自動化應該可以更好的協調在一起，而不是采用目前這種臨時的笨辦法;

　　<!--[if !supportLists]-->5) <!--[endif]-->新的內測版本的上傳更新可以做到更加的自動化，而不需要在手動的將穩定版本上傳至服務器上;

　　寫了這么多，更希望的是拋磚引玉，希望收到大家更多的建議和反饋，更希望可以從大家那里學到新的東西，拋棄目前的一些淺顯的做法!

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