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

　　Xcode Plugin可以構建ipa包，因此在這一步可以將正式環境的內測ipa包生成出來;

　　<!--[if !supportLists]-->4) <!--[endif]-->自動化驗證;自動化腳本驗證之后的版本就是穩定版本，可以提供給外部進行內測，因此自動化腳本要求覆蓋應用的主要功能點，保證這些功能點的功能正確性，注意自動化驗證的版本的環境一般是測試環境;

　　<!--[if !supportLists]-->5) <!--[endif]-->內測版本上傳;自動化驗證針對的是測試環境，在自動化測試通過之后將相應的正式版本上傳至內測應用下載服務器，該步驟需要和服務端約定一個更新的規約，如果沒有規約則需要手動上傳，注意如果沒有辦法自動上傳需要將穩定版本進行存儲;

　　上面說了本地生活在這兩個iOS客戶端測試中遇見的問題和一些解決辦法，整理了一個大體的思路，那么在后面的部分針對每一部分進行詳細說明，聊聊現在本地的做法，也說說自己的思路;

　　說說實踐：

　　關于代碼更新：

　　代碼更新沒有什么好說的，需要進行代碼更新的有兩個地方，一個是在每次build之前使用更新代碼，另一個是在每次進行自動化驗證之前更新自動化測試的代碼;

　　一般來說工程的svn庫和自動化測試腳本的svn庫是分開的，所以在這里采用了最簡單的處理方式，將整個流程拆開，拆分為2個Job，一個是針對客戶端工程的代碼庫，該Job負責代碼的靜態檢查和build工作，另一個是針對測試腳本的代碼庫，該Job負責自動化驗證工作;

　　關于靜態檢查：

　　Xcode中集成了Clang Static Analyze檢查器，通過該檢查器可以對工程進行靜態分析，通過分析可以找出代碼中存在的潛在問題，如潛在的內存泄露、變量未賦值就使用、變量定義之后沒有使用或者除零等邏輯錯誤;

　　目前為了保證版本發布的質量，減少潛在的風險和開發進行了規約，在每次提交之前對于代碼進行靜態檢查并對檢查結果修復;

　　在Xcode中使用Analyze的方式如下：

　　Product->Analyze

　　在上圖中的左邊欄中的藍色標示就是存在潛在問題的地方，開發和測試的同學都需要對這些地方加以注意，對于每個問題進行分析;目前本地的規約如下：

　　<!--[if !supportLists]-->1) <!--[endif]-->如果該問題是由于第三方庫帶入的，或者第三方庫的問題在不需要修復;

　　<!--[if !supportLists]-->2) <!--[endif]-->如果該問題發生在非第三方庫的代碼中，并且確認是一個問題就需要修復;

　　<!--[if !supportLists]-->3) <!--[endif]-->如果該問題發生在非第三方庫的代碼中，并且確認不是一個問題不需要修復;

　　關于代碼靜態檢查最好是針對iphoneos(最好不要采用iOSSimulator)的Release版本進行靜態掃描;在Xcode中可以通過Product->Edit Scheme來進行設置：

　　那是否只能通過Xcode來進行代碼靜態掃描呢?有沒有更加懶的辦法來自動的進行這個工作呢?答案是有的，Jenkins提供了一個插件叫做Clang Scan-Build，通過這個插件可以對代碼進行靜態檢查，該插件使用的也是Clang，和Xcode是一樣的，該插件最終將生成xml的報告，在Analyze之后可以發布報告;

　　在jenkins中設置如下：

　　在我們的工程中的一些問題可能是第三方引起的，本工程中沒有辦法進行處理，而這些問題可能會導致認為工程的build版本為不穩定版本，該插件提供一種簡單的方式來處理這種情況，插件提供一個閥值，當超過這個閥值的時候才會認為工程是不穩定的版本，這個時候只需要統計出沒有辦法進行處理的問題數目，然后將閥值設為這些問題的個數;

　　關于自動構建：

　　Xcode提供了命令行工具來通過命令行進行工程的構建，在Xcode4.5中命令行工具是默認不安裝的，因此需要首先安裝命令行工具，安裝方式如下：

　　安裝完成之后就可以使用xcodebuild命令來進行工程的構建了;

　　開始的時候工程的構建是通過shell腳本來進行的，后來發現在jenkins中提供了一個Xcode Plugin的插件，通過該插件可以可視化的配置build的參數，這個插件最終使用的仍然是xcodebuild的命令行;Xcode構建的配置如下：

　　這里的配置項的用法和說明在后面的提示中都有包括，那么說說項目中的一些需求，基本上現在的項目測試自動化腳本都是在測試環境運行，然后發布的內測包都是線上環境的，而又不想把這樣的工作通過jenkins中的兩個Job來實現，因此這里的處理方式是設置了兩個Xcode Step，第一個構建測試環境下用于進行自動化驗證的版本(上圖)，第二個用于構建內測版本的線上環境(下圖);

　　兩者之間提供腳本進行環境的切換，目前的問題在于由于各個項目的開發不同，因此用來做環境切換的方式也會不同，這樣就導致了需要為每一個項目提供一個如下的環境切換腳本：

　　用于在構建測試版本之前把環境切換至測試環境;

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