關於iOS自動化打包的一些分享

說到自動化打包, 相信你們在平常開發中都有所接觸, 尤爲是在多分支並行開發的狀況下, 自動化打包顯得尤其重要, 不少時候, 咱們打包通常是打及成分支的包, 開發卻在開發分支上, 若是採起手動打包, 咱們須要反覆切分支, 不只影響工做效率, 並且會打斷咱們的開發思惟, 而卻在工程較大的狀況下, xcode每次indexing須要的時間就好久。

即便對於不少單分支開發的小項目來講, 自動化打 包的優點也是不言而喻的, 由於在手動打包的同時, 基本能夠說是什麼事都作不了的, 你須要一步步等待archive, export這些機械化的步驟。而有了自動化打包, 你只須要點擊一個按鈕, 即可以繼續本身的開發。因此, 自動化打包勢在必行。

本文主要記錄了我在公司自動化打包佈置中的一些探索, 及各平臺的優缺點和配置過程踩過的坑。

談到iOS的持續集成, 咱們首先想到的必定會是jenkins, 這裏我先介紹下我司採用的Mac OS Server(如下簡稱Server)這個平臺的一些優缺點。

Server相比於jenkins, 我總結優勢有三:

1. 相比於jenkins的各類繁瑣配置, Server配置簡單, 全程基本下一步操做便可;
2. 直接使用xcode就可開始構建項目, 而不須要登陸網頁;
3. 集成度至關高, 沒有特別的需求, 基本能夠不寫腳本, 只須要配置一個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的一些配置注意事項:

如下是我在配置過程當中踩到的一些坑:

1. 8080端口被其餘程序佔用, 啓動失敗: java -jar jenkins.war —httpPort=8082;
2. git權限須要告訴jenkins私鑰, 而不是git上的公鑰: cat ~/.ssh/id_rsa;

接下來, 其餘用戶直接經過瀏覽器登陸 http://192.168.0.xxx:8082 , 經過帳號密碼登陸, 即可以配置和構建項目。

jenkins相對Mac OS Server的優勢:

1. 同一局域網即可以登陸, 登陸以後即可以自行配置項目
2. 彷佛能夠並行構建任務

當使用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	可選參數, 可不傳

這樣彷佛能夠用一臺服務器, 將打包任務部署到指定機器上:

這樣能夠在一臺機器上集成公司不一樣端的項目, 並且還不影響打包效率。

關於Server和jenkins的一些總結:

1. 若是僅僅是iOS端的打包, Server是徹底夠用了, 並且操做貼近咱們平時的開發風格, 雖然網頁沒法配置, 可是對於大部分公司來講, 打包配置都是開發在作的, 而不是測試;
2. 對於iOS端小型項目來講, 沒有特別多的分支, 直接能夠多建幾個bot, 從而避開手寫腳本;
3. 若是多端同一服務器, 那麼jenkins無疑有較大的優點；若是公司有足夠的電腦做爲分佈打包服務器, 那麼打包效率會更上一層樓。

fastlane及打包腳本簡單介紹

說到自動化打包, 就不得不談當下很是流行的fastlane, 若是說Server和jenkins是同一維度的, 都是打包平臺, 那麼fastlane應該是和shell腳原本做比較, 或者能夠說, fastlane是在shell的基礎上封裝了一層, fastlane相比於腳本打包, 短暫體驗後, 我以爲優勢主要有:

1. 避免繁瑣的路徑拼接, 拷貝等
2. 修改工程配置文件, 避免調試時修改配置文件不當心提交到遠程分支, 致使打包失敗

咱們來簡單看一段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就能夠避免這個煩惱。

總結

本文主要是團隊中的一次分享後的整理, 並非特別細緻的教程, 只是對當下的自動化打包的一些嘗試及過程當中遇到的一些問題和本身的一點思考, 若是有說的不對的地方, 望不吝賜教。