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