CocoaPods最佳實踐探討

近期在項目中首次使用了CocoaPods。從軟件工程的角度來看，我對目前常見的CocoaPods使用方法有些意見，建議作一些改進。先說一下我建議的最佳實踐，後面再分析爲何要這樣作。而且但願你們根據本身公司的狀況，討論一下這幾項建議是否合理，一塊兒搞出一份真正的「最佳實踐」。

 

CocoaPods的常見使用方法參見唐巧的文章《用CocoaPods作iOS程序的依賴管理》。在他的基礎上，我提出幾條補充。

 

1. CocoaPods生成的Pods目錄*不*加入.gitignore，也就是說，第三方庫的源碼或binary要和產品代碼一塊兒，提交到公司內部的版本控制系統上。每次修改Podfile並執行pod update後，把Podfile、Podfile.lock、Pods目錄下的改動一併簽入。

2. 保證在任什麼時候候只簽出一次代碼就能直接編譯執行，不須要執行pod命令，甚至能夠不裝CocoaPods就能參與開發。

3. Podfile裏全部的庫使用精確版本號，不使用任何’~> 1.0', ‘>= 1.0'之類的版本號語法，只使用精確的版本號如'1.3.2'。

4. 在項目開發過程當中，能夠每隔一段時間使用pod outdated命令手動檢查各第三方庫是否有更新。若是發現某個庫有新版本，去第三方庫主頁查看更新記錄，並對版本變更作評估。若是確認有必要更新到最新版本，則修改Podfile裏的版本號到最新版本，執行pod update。

5. 若是兩我的同時修改了Podfile，第二我的git pull後發現有conflict，resolve順序是：不動其餘文件，先手動resolve Podfile的衝突；而後執行pod update；若是仍有衝突，能夠用git reset把Podfile.lock和Pods目錄恢復原狀，再次執行pod update。此時應該沒有pod相關的衝突了。

 

------------------------------------

 

如下分析常見CocoaPods用法的問題，首先看CocoaPods官網上的示例Podfile。

 

source 'https://github.com/CocoaPods/Specs.git'

pod 'AFNetworking', '~> 1.0'

 

這兩行的含義是，使用github上的pods spec，安裝AFNetworking 1.x系列最新的那個版本；若是AFNetworking還依賴於其餘庫，自動安裝合適的版本。

 

假設如今咱們的項目中要用到第三方庫XYZ，開發流程大體以下：

1. 項目建立者張三在本身機器上安裝好CocoaPods。

2. 張三執行pod init，在Podfile裏添加代碼 pod 'XYZ', '~> 1.0'。執行pod install，把Podfile和Podfile.lock簽入代碼管理，Pods目錄添加到.gitignore。

3. 項目開發人員李四安裝好CocoaPods。

4. 李四簽出代碼，編譯，發現pod報錯。因而執行pod install後，從新編譯經過。

 

這樣的CocoaPods使用方法可能引起不少異常狀況。考慮第一類場景：

1. Github忽然被盾了（曾經發生過）、或公司的外網出口掛了，李四沒法成功執行pod install，所以只能眼巴巴的看着項目代碼，沒法編譯。此時張三說，把我本地的Pods目錄都拷給你一份吧，雖然這樣拷來拷去容易出錯，但暫時先這樣臨時解決吧。

2. Github忽然被盾了，公司的持續集成服務器上沒法執行pod install，也無法給服務器拷一份Pods目錄。因而連續多天沒法用持續集成。

3. XYZ開發者在修改代碼時，從git上刪除了最新版本的tag，並從新加tag到另外一次commit上。因而張三和李四獲得的XYZ代碼是不一樣的。（雖然AFNetworking開發者頗有經驗，不太可能出這種錯，但其餘小的第三方庫就不必定了。）

4. 五年後，早就沒人使用古老的iOS 7了。XYZ開發者認爲該庫是針對iOS 7的，技術已經太陳舊，因而從Github上刪除了該項目。（還好咱們三年前就再也不用這個庫了。）但某一天公司有個新項目，想參考之前的代碼。當打開代碼執行pod install時，發現Github上已經沒有XYZ庫了。

 

以上狀況能夠歸結爲：你的代碼是否可用嚴重依賴於別人。你從公司的版本控制系統上獲取的代碼不能直接編譯，還依賴於世界各地不少其餘人是否正確配置了他們的代碼，還依賴於Github等git服務商是否可用，等等。在極端狀況下，會有災難性後果。

 

再看第二類場景：

5. 在咱們項目的開發過程當中，XYZ最新版本是1.4。一年後，咱們從新打開舊的項目代碼，執行pod install，獲取到XYZ 1.x系列的最新版本1.7版。在XYZ 1.4到1.7版本之間，改變了一些接口和實現，咱們的項目代碼頗有可能沒法編譯，或沒法正確執行。

 

這裏的問題是：常見的版本號寫法'~> 1.0’會在pod install或pod update時檢查版本更新，隨時將第三方庫升級到1.x系列的最新版本。對正在開發的項目來講，常常升級第三方庫是能夠的。但對已經發布的產品代碼，這個變更是不可接受的。已發佈的版本必需要有一份固定不變的代碼，不然配置管理就失去了意義。

 

還有第三類場景：

6. 張三的CocoaPods安裝的很早，和李四機器上的不是同一版本。這兩個版本的CocoaPods對依賴規則的resolve算法不一樣，所以李四pod install失敗，沒法下載到和張三相同的第三方庫代碼。這是真事，兩週前咱們剛剛遇到了，後來解決方法是全部人都強制安裝某個舊版本的CocoaPods。

 

這裏的問題是：CocoaPods做爲開發工具鏈中重要的一環，它的質量是否有保證？CocoaPods不是蘋果官方的工具，也不是像git那樣由極富經驗的人組織設計開發，咱們可否信任它的版本兼容性？具體來講，即無論用什麼版本的CocoaPods，pod install後獲得基本相同的第三方庫。咱們看到最近已經出了一個bug，若是時間再長點，三年後的CocoaPods會不會跟今天有較大差別？

對這個問題的一個解決方法是要求全部項目成員安裝相同版本的CocoaPods，甚至安裝相同版本的Ruby。但一我的須要同時參與多個項目的怎麼辦？問題的根源仍是沒變。

 

------------------------------------

 

基於以上分析，我提議的「最佳實踐」解決了如下問題。

* Pods目錄簽入到版本控制系統，使產品代碼沒有外部依賴，無論何時都能從公司內網獲取一份可直接運行的代碼。

* 已發佈版本的產品代碼永久固定，不會隨時間而變化，方便追蹤問題和存檔。

* 不要求項目成員裝一樣版本的CocoaPods，甚至能夠不裝CocoaPods。下降測試、設計人員使用代碼的難度，也避免了CocoaPods自己兼容性引發的問題。

 

轉自：http://www.weibo.com/p/1001603800875490492754