?????說到自動化打包, 相信大家在日常開發(fā)中都有所接觸, 尤其是在多分支并行開發(fā)的情況下, 自動化打包顯得尤為重要, 很多時候, 我們打包一般是打及成分支的包, 開發(fā)卻在開發(fā)分支上, 如果采取手動打包, 我們需要反復切分支, 不僅影響工作效率, 而且會打斷我們的開發(fā)思維, 而卻在工程較大的情況下, xcode每次indexing需要的時間就很久。
????????即使對于很多單分支開發(fā)的小項目來說, 自動化打 包的優(yōu)勢也是不言而喻的, 因為在手動打包的同時, 基本可以說是什么事都做不了的, 你需要一步步等待archive, export這些機械化的步驟剩彬。而有了自動化打包, 你只需要點擊一個按鈕, 便可以繼續(xù)自己的開發(fā)俩块。所以, 自動化打包勢在必行划煮。
本文主要記錄了我在公司自動化打包布置中的一些探索, 及各平臺的優(yōu)缺點和配置過程踩過的坑屎飘。
????????談到iOS的持續(xù)集成, 我們首先想到的一定會是jenkins, 這里我先介紹下我司采用的Mac OS Server(以下簡稱Server)這個平臺的一些優(yōu)缺點。
Server相比于jenkins, 我總結優(yōu)點有三
相比于jenkins的各種繁瑣配置, Server配置簡單, 全程基本下一步操作即可;
直接使用xcode就可開始構建項目, 而不需要登錄網(wǎng)頁;
集成度相當高, 沒有特別的需求, 基本可以不寫腳本, 只需要配置一個plist文件即可以打包轻姿。
這里不做過多的配置介紹, 雖然Server沒有jenkins熱門, 但網(wǎng)上的文章也比比皆是, 而且如上優(yōu)點1中所說, Server配置真的很簡單, 在證書乳乌、描述文件齊全的情況下, 基本就是一直點下一步操作。
下面我介紹使用過程中需要注意的一些方面:
如上圖所示, 上圖是對bot的各種設置, 一個bot對應一個獨立工作空間, 如果有了解jenkins的話, bot可以類比jenkins的一個項目叙淌。
如果對打包沒有特別需求, 勾選Archive, 選擇對應Scheme沥割、Configuration, 指定一個plist文件, 后面的Triggers不需要寫任何代碼, 便可以打出對應的包。
上面所說的plist文件大體結構是這樣的:
這個plist文件對應一系列的參數(shù), 并不需要我們自己寫, 手動打一次包, 即可導出這個文件凿菩。這里順便提一句, Server配置好后, 連接此Server后, 任意機器都可以上傳此plist文件, Server是將上傳的plist文件拷貝到當前Bot工作目錄下机杜。
在Server配置好后, 即使是windows電腦也可以通過ip或者自簽證書登錄, https://192.168.0.xxx/xcode/lastest 或 https://xxxdemac-mini.local/xcode/bots/latest, 登陸后會顯示以下界面, 點擊integration, 便可以開始集成了, 但是這里似乎只能夠集成, 不能配置, 不過根據(jù)Apple的慣性, 想要構造自己的生態(tài), 我們也是能理解的。
關于jenkins的一些配置注意事項
以下是我在配置過程中踩到的一些坑：
8080端口被其他程序占用, 啟動失敗: java -jar jenkins.war —httpPort=8082;
git權限需要告訴jenkins私鑰, 而不是git上的公鑰: cat ~/.ssh/id_rsa;
接下來, 其他用戶直接通過瀏覽器登錄 http://192.168.0.xxx:8082 , 通過賬號密碼登錄, 便可以配置和構建項目衅谷。
jenkins相對Mac OS Server的優(yōu)點：
同一局域網(wǎng)便可以登錄, 登錄之后便可以自行配置項目
似乎可以并行構建任務
當使用Mac OS Server進行打包, 無論進行多少個打包任務, 它只開啟一個xcodebuild進程
而使用jenkins進行多項目打包, 這里開始構建兩個項目就開啟兩個進程(下圖上面兩個xcodebuild進程是jenkins開啟)
這里我沒有做定量的測試, 猜想是jenkins的效率稍優(yōu), 對于多核處理器, 相同的計算能力, 對于兩個構建來說, 應該沒多大差距, 但對于拉代碼等耗時操作, 比起Server其他構建任務在排隊, 這部分就能省上一些時間椒拗。
但是jenkins有更方便的打包方式: jenkins開啟token, 不需要用戶名登錄便可以打包:
這樣給構建項目設置后還是不行的, 因為jenkins覺得這樣是不安全的, 拿到了token就可以做任何事了。 系統(tǒng)管理->全局安全配置->勾選 Allow anonymous read access
接著, 我們便可以通過命令來打包:
curl http://10.24.113.24:8082/job/notification_extension_test/build\?token\=123\&cause\=testBuild
這樣似乎可以用一臺服務器, 將打包任務部署到指定機器上:
這樣可以在一臺機器上集成公司不同端的項目, 而且還不影響打包效率获黔。
關于Server和jenkins的一些總結：
如果僅僅是iOS端的打包, Server是完全夠用了, 而且操作貼近我們平時的開發(fā)風格, 雖然網(wǎng)頁無法配置, 但是對于大部分公司來說, 打包配置都是開發(fā)在做的, 而不是測試;
對于iOS端小型項目來說, 沒有特別多的分支, 直接可以多建幾個bot, 從而避開手寫腳本;
如果多端同一服務器, 那么jenkins無疑有較大的優(yōu)勢蚀苛；如果公司有足夠的電腦作為分布打包服務器, 那么打包效率會更上一層樓。
fastlane及打包腳本簡單介紹
說到自動化打包, 就不得不談當下非常流行的fastlane, 如果說Server和jenkins是同一維度的, 都是打包平臺, 那么fastlane應該是和shell腳本來作比較, 或者可以說, fastlane是在shell的基礎上封裝了一層, fastlane相比于腳本打包, 短暫體驗后, 我覺得優(yōu)點主要有：
避免繁瑣的路徑拼接, 拷貝等
修改工程配置文件, 避免調試時修改配置文件不小心提交到遠程分支, 導致打包失敗
我們來簡單看一段fastlane的打包代碼:
上述代碼參數(shù)基本見名知意, 不難看出, 這基本就是給之前Server的exportPlist文件的一種包裝, 只需執(zhí)行
fastlane adhocMyApp version:100000 // 100000是傳的版本號
便可以自動打出一個包, 并導出dSYM文件, 這里我故意把Distribution的provisioning Profile改成企業(yè)的
發(fā)現(xiàn)工程配置文件發(fā)生了改變, 這里比較暴力, 把每種configuration的Provisioning Profile和teamID全都改了
我們再看終端, 看看fastlane究竟做了些啥
也確實和上圖一樣, 把所有都改成了AdHoc的玷氏。在進行修改配置后, 最終也是執(zhí)行打包的核心腳本:
// 對應手動打包archive
xcodebuild archive -workspace ${work_space} -scheme ${scheme} -configuration ${configurationRelease} -archivePath ${archivePath}
// 對應導出步驟
xcodebuild -exportArchive -archivePath ${archivePath} -exportPath ${exportPath} -exportOptionsPlist ${exportOptionsPlist}
上述腳本的參數(shù)也基本見名知意, 腳本中${work_space}等代表取一個變量的值, 這里都是各個配置對應的路徑或字符串堵未。
經(jīng)歷上述腳本后, 就會在指定的exportPath路徑下生成.ipa文件。我們一般是要將ipa和dSYM文件copy到指定的文件夾供測試去取, 后面便是一段處理繁瑣的路徑的腳本, 腳本本身沒任何難度, 但是要格外注意, 且測試起來需要花費一定的時間, 如果使用fastlane就可以避免這個煩惱盏触。
