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

LoyalToOrigin發表於2018-01-11
iOS

說到自動化打包, 相信大家在日常開發中都有所接觸, 尤其是在多分支並行開發的情況下, 自動化打包顯得尤為重要, 很多時候, 我們打包一般是打及成分支的包, 開發卻在開發分支上, 如果採取手動打包, 我們需要反覆切分支, 不僅影響工作效率, 而且會打斷我們的開發思維, 而卻在工程較大的情況下, xcode每次indexing需要的時間就很久。

即使對於很多單分支開發的小專案來說, 自動化打 包的優勢也是不言而喻的, 因為在手動打包的同時, 基本可以說是什麼事都做不了的, 你需要一步步等待archive, export這些機械化的步驟。而有了自動化打包, 你只需要點選一個按鈕, 便可以繼續自己的開發。所以, 自動化打包勢在必行。

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

談到iOS的持續整合, 我們首先想到的一定會是jenkins, 這裡我先介紹下我司採用的Mac OS Server(以下簡稱Server)這個平臺的一些優缺點。

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

  1. 相比於jenkins的各種繁瑣配置, Server配置簡單, 全程基本下一步操作即可;
  2. 直接使用xcode就可開始構建專案, 而不需要登入網頁;
  3. 整合度相當高, 沒有特別的需求, 基本可以不寫指令碼, 只需要配置一個plist檔案即可以打包。

這裡不做過多的配置介紹, 雖然Server沒有jenkins熱門, 但網上的文章也比比皆是, 而且如上優點1中所說, Server配置真的很簡單, 在證照、描述檔案齊全的情況下, 基本就是一直點下一步操作。

下面我介紹使用過程中需要注意的一些方面:

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

如上圖所示, 上圖是對bot的各種設定, 一個bot對應一個獨立工作空間, 如果有了解jenkins的話, bot可以類比jenkins的一個專案。

如果對打包沒有特別需求, 勾選Archive, 選擇對應Scheme、Configuration, 指定一個plist檔案, 後面的Triggers不需要寫任何程式碼, 便可以打出對應的包。

上面所說的plist檔案大體結構是這樣的:

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

這個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的慣性, 想要構造自己的生態, 我們也是能理解的。

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

關於jenkins的一些配置注意事項:

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

  1. 8080埠被其他程式佔用, 啟動失敗: java -jar jenkins.war —httpPort=8082;
  2. git許可權需要告訴jenkins私鑰, 而不是git上的公鑰: cat ~/.ssh/id_rsa;

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

接下來, 其他使用者直接通過瀏覽器登入 http://192.168.0.xxx:8082 , 通過賬號密碼登入, 便可以配置和構建專案。

jenkins相對Mac OS Server的優點:

  1. 同一區域網便可以登入, 登入之後便可以自行配置專案
  2. 似乎可以並行構建任務

當使用Mac OS Server進行打包, 無論進行多少個打包任務, 它只開啟一個xcodebuild程式

關於iOS自動化打包的一些分享
而使用jenkins進行多專案打包, 這裡開始構建兩個專案就開啟兩個程式(下圖上面兩個xcodebuild程式是jenkins開啟)
關於iOS自動化打包的一些分享
這裡我沒有做定量的測試, 猜想是jenkins的效率稍優, 對於多核處理器, 相同的計算能力, 對於兩個構建來說, 應該沒多大差距, 但對於拉程式碼等耗時操作, 比起Server其他構建任務在排隊, 這部分就能省上一些時間。

但是jenkins有更方便的打包方式: jenkins開啟token, 不需要使用者名稱登入便可以打包:

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

這樣給構建專案設定後還是不行的, 因為jenkins覺得這樣是不安全的, 拿到了token就可以做任何事了。 系統管理->全域性安全配置->勾選 Allow anonymous read access

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

接著, 我們便可以通過命令來打包:

curl http://10.24.113.24:8082/job/notification_extension_test/build\?token\=123\&cause\=testBuild
複製程式碼
引數 註釋
notification_extension_test 專案名稱
token 上面設定的token
cause 可選引數, 可不傳

這樣似乎可以用一臺伺服器, 將打包任務部署到指定機器上:

關於iOS自動化打包的一些分享
這樣可以在一臺機器上整合公司不同端的專案, 而且還不影響打包效率。

關於Server和jenkins的一些總結:

  1. 如果僅僅是iOS端的打包, Server是完全夠用了, 而且操作貼近我們平時的開發風格, 雖然網頁無法配置, 但是對於大部分公司來說, 打包配置都是開發在做的, 而不是測試;
  2. 對於iOS端小型專案來說, 沒有特別多的分支, 直接可以多建幾個bot, 從而避開手寫指令碼;
  3. 如果多端同一伺服器, 那麼jenkins無疑有較大的優勢；如果公司有足夠的電腦作為分佈打包伺服器, 那麼打包效率會更上一層樓。

fastlane及打包指令碼簡單介紹

說到自動化打包, 就不得不談當下非常流行的fastlane, 如果說Server和jenkins是同一維度的, 都是打包平臺, 那麼fastlane應該是和shell指令碼來作比較, 或者可以說, fastlane是在shell的基礎上封裝了一層, fastlane相比於指令碼打包, 短暫體驗後, 我覺得優點主要有:

  1. 避免繁瑣的路徑拼接, 拷貝等
  2. 修改工程配置檔案, 避免除錯時修改配置檔案不小心提交到遠端分支, 導致打包失敗

我們來簡單看一段fastlane的打包程式碼:

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

上述程式碼引數基本見名知意, 不難看出, 這基本就是給之前Server的exportPlist檔案的一種包裝, 只需執行

fastlane adhocMyApp version:100000  // 100000是傳的版本號
複製程式碼

便可以自動打出一個包, 並匯出dSYM檔案, 這裡我故意把Distribution的provisioning Profile改成企業的

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

發現工程配置檔案發生了改變, 這裡比較暴力, 把每種configuration的Provisioning Profile和teamID全都改了

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

我們再看終端, 看看fastlane究竟做了些啥

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

也確實和上圖一樣, 把所有都改成了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就可以避免這個煩惱。

總結

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

相關文章