說(shuō)到自動(dòng)化打包, 相信大家在日常開(kāi)發(fā)中都有所接觸, 尤其是在多分支并行開(kāi)發(fā)的情況下, 自動(dòng)化打包顯得尤為重要, 很多時(shí)候, 我們打包一般是打及成分支的包, 開(kāi)發(fā)卻在開(kāi)發(fā)分支上, 如果采取手動(dòng)打包, 我們需要反復(fù)切分支, 不僅影響工作效率, 而且會(huì)打斷我們的開(kāi)發(fā)思維, 而卻在工程較大的情況下, xcode每次indexing需要的時(shí)間就很久。

即使對(duì)于很多單分支開(kāi)發(fā)的小項(xiàng)目來(lái)說(shuō), 自動(dòng)化打 包的優(yōu)勢(shì)也是不言而喻的, 因?yàn)樵谑謩?dòng)打包的同時(shí), 基本可以說(shuō)是什么事都做不了的, 你需要一步步等待archive, export這些機(jī)械化的步驟。而有了自動(dòng)化打包, 你只需要點(diǎn)擊一個(gè)按鈕, 便可以繼續(xù)自己的開(kāi)發(fā)。所以, 自動(dòng)化打包勢(shì)在必行。

在這里我還是要推薦下我自己建的iOS開(kāi)發(fā)學(xué)習(xí)群：680565220，群里都是學(xué)ios開(kāi)發(fā)的，如果你正在學(xué)習(xí)ios ，小編歡迎你加入，今天分享的這個(gè)案例已經(jīng)上傳到群文件，大家都是軟件開(kāi)發(fā)黨，不定期分享干貨（只有iOS軟件開(kāi)發(fā)相關(guān)的），包括我自己整理的一份2018最新的iOS進(jìn)階資料和高級(jí)開(kāi)發(fā)教程

本文主要記錄了我在公司自動(dòng)化打包布置中的一些探索, 及各平臺(tái)的優(yōu)缺點(diǎn)和配置過(guò)程踩過(guò)的坑。

談到iOS的持續(xù)集成, 我們首先想到的一定會(huì)是jenkins, 這里我先介紹下我司采用的Mac OS Server(以下簡(jiǎn)稱(chēng)Server)這個(gè)平臺(tái)的一些優(yōu)缺點(diǎn)。

Server相比于jenkins, 我總結(jié)優(yōu)點(diǎn)有三:

相比于jenkins的各種繁瑣配置, Server配置簡(jiǎn)單, 全程基本下一步操作即可;

直接使用xcode就可開(kāi)始構(gòu)建項(xiàng)目, 而不需要登錄網(wǎng)頁(yè);

集成度相當(dāng)高, 沒(méi)有特別的需求, 基本可以不寫(xiě)腳本, 只需要配置一個(gè)plist文件即可以打包。

這里不做過(guò)多的配置介紹, 雖然Server沒(méi)有jenkins熱門(mén), 但網(wǎng)上的文章也比比皆是, 而且如上優(yōu)點(diǎn)1中所說(shuō), Server配置真的很簡(jiǎn)單, 在證書(shū)、描述文件齊全的情況下, 基本就是一直點(diǎn)下一步操作。

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

如上圖所示, 上圖是對(duì)bot的各種設(shè)置, 一個(gè)bot對(duì)應(yīng)一個(gè)獨(dú)立工作空間, 如果有了解jenkins的話(huà), bot可以類(lèi)比jenkins的一個(gè)項(xiàng)目。

如果對(duì)打包沒(méi)有特別需求, 勾選Archive, 選擇對(duì)應(yīng)Scheme、Configuration, 指定一個(gè)plist文件, 后面的Triggers不需要寫(xiě)任何代碼, 便可以打出對(duì)應(yīng)的包。

上面所說(shuō)的plist文件大體結(jié)構(gòu)是這樣的:

這個(gè)plist文件對(duì)應(yīng)一系列的參數(shù), 并不需要我們自己寫(xiě), 手動(dòng)打一次包, 即可導(dǎo)出這個(gè)文件。這里順便提一句, Server配置好后, 連接此Server后, 任意機(jī)器都可以上傳此plist文件, Server是將上傳的plist文件拷貝到當(dāng)前Bot工作目錄下。

在Server配置好后, 即使是windows電腦也可以通過(guò)ip或者自簽證書(shū)登錄,

https://192.168.0.xxx/xcode/lastest 或 https://xxxdemac-mini.local/xcode/bots/latest, 登陸后會(huì)顯示以下界面, 點(diǎn)擊integration, 便可以開(kāi)始集成了, 但是這里似乎只能夠集成, 不能配置, 不過(guò)根據(jù)Apple的慣性, 想要構(gòu)造自己的生態(tài), 我們也是能理解的。

關(guān)于jenkins的一些配置注意事項(xiàng):

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

8080端口被其他程序占用, 啟動(dòng)失敗: java -jar jenkins.war —httpPort=8082;

git權(quán)限需要告訴jenkins私鑰, 而不是git上的公鑰: cat ~/.ssh/id_rsa;

接下來(lái), 其他用戶(hù)直接通過(guò)瀏覽器登錄 http://192.168.0.xxx:8082 , 通過(guò)賬號(hào)密碼登錄, 便可以配置和構(gòu)建項(xiàng)目。

jenkins相對(duì)Mac OS Server的優(yōu)點(diǎn):

同一局域網(wǎng)便可以登錄, 登錄之后便可以自行配置項(xiàng)目

似乎可以并行構(gòu)建任務(wù)

當(dāng)使用Mac OS Server進(jìn)行打包, 無(wú)論進(jìn)行多少個(gè)打包任務(wù), 它只開(kāi)啟一個(gè)xcodebuild進(jìn)程

而使用jenkins進(jìn)行多項(xiàng)目打包, 這里開(kāi)始構(gòu)建兩個(gè)項(xiàng)目就開(kāi)啟兩個(gè)進(jìn)程(下圖上面兩個(gè)xcodebuild進(jìn)程是jenkins開(kāi)啟)

這里我沒(méi)有做定量的測(cè)試, 猜想是jenkins的效率稍?xún)?yōu), 對(duì)于多核處理器, 相同的計(jì)算能力, 對(duì)于兩個(gè)構(gòu)建來(lái)說(shuō), 應(yīng)該沒(méi)多大差距, 但對(duì)于拉代碼等耗時(shí)操作, 比起Server其他構(gòu)建任務(wù)在排隊(duì), 這部分就能省上一些時(shí)間。

但是jenkins有更方便的打包方式:

jenkins開(kāi)啟token, 不需要用戶(hù)名登錄便可以打包:

這樣給構(gòu)建項(xiàng)目設(shè)置后還是不行的, 因?yàn)閖enkins覺(jué)得這樣是不安全的, 拿到了token就可以做任何事了。

系統(tǒng)管理->全局安全配置->勾選 Allow anonymous read access

接著, 我們便可以通過(guò)命令來(lái)打包:

curl http://10.24.113.24:8082/job/notification_extension_test/build?token=123&cause=testBuild

參數(shù)注釋

notification_extension_test??項(xiàng)目名稱(chēng) ??

token??上面設(shè)置的token??

cause可選參數(shù), 可不傳

這樣似乎可以用一臺(tái)服務(wù)器, 將打包任務(wù)部署到指定機(jī)器上:

這樣可以在一臺(tái)機(jī)器上集成公司不同端的項(xiàng)目, 而且還不影響打包效率。

關(guān)于Server和jenkins的一些總結(jié):

如果僅僅是iOS端的打包, Server是完全夠用了, 而且操作貼近我們平時(shí)的開(kāi)發(fā)風(fēng)格, 雖然網(wǎng)頁(yè)無(wú)法配置, 但是對(duì)于大部分公司來(lái)說(shuō), 打包配置都是開(kāi)發(fā)在做的, 而不是測(cè)試;

對(duì)于iOS端小型項(xiàng)目來(lái)說(shuō), 沒(méi)有特別多的分支, 直接可以多建幾個(gè)bot, 從而避開(kāi)手寫(xiě)腳本;

如果多端同一服務(wù)器, 那么jenkins無(wú)疑有較大的優(yōu)勢(shì)；如果公司有足夠的電腦作為分布打包服務(wù)器, 那么打包效率會(huì)更上一層樓。

fastlane及打包腳本簡(jiǎn)單介紹

說(shuō)到自動(dòng)化打包, 就不得不談當(dāng)下非常流行的fastlane, 如果說(shuō)Server和jenkins是同一維度的, 都是打包平臺(tái), 那么fastlane應(yīng)該是和shell腳本來(lái)作比較, 或者可以說(shuō), fastlane是在shell的基礎(chǔ)上封裝了一層, fastlane相比于腳本打包, 短暫體驗(yàn)后, 我覺(jué)得優(yōu)點(diǎn)主要有:

避免繁瑣的路徑拼接, 拷貝等

修改工程配置文件, 避免調(diào)試時(shí)修改配置文件不小心提交到遠(yuǎn)程分支, 導(dǎo)致打包失敗

我們來(lái)簡(jiǎn)單看一段fastlane的打包代碼:

上述代碼參數(shù)基本見(jiàn)名知意, 不難看出, 這基本就是給之前Server的exportPlist文件的一種包裝, 只需執(zhí)行

fastlane adhocMyApp version:100000? // 100000是傳的版本號(hào)

便可以自動(dòng)打出一個(gè)包, 并導(dǎo)出dSYM文件, 這里我故意把Distribution的provisioning Profile改成企業(yè)的

發(fā)現(xiàn)工程配置文件發(fā)生了改變, 這里比較暴力, 把每種configuration的Provisioning Profile和teamID全都改了

我們?cè)倏唇K端, 看看fastlane究竟做了些啥

也確實(shí)和上圖一樣, 把所有都改成了AdHoc的。在進(jìn)行修改配置后, 最終也是執(zhí)行打包的核心腳本:

// 對(duì)應(yīng)手動(dòng)打包archive

xcodebuild archive -workspace ${work_space} -scheme ${scheme} -configuration ${configurationRelease} -archivePath ${archivePath}

// 對(duì)應(yīng)導(dǎo)出步驟

xcodebuild -exportArchive -archivePath ${archivePath} -exportPath ${exportPath} -exportOptionsPlist ${exportOptionsPlist}

上述腳本的參數(shù)也基本見(jiàn)名知意, 腳本中${work_space}等代表取一個(gè)變量的值, 這里都是各個(gè)配置對(duì)應(yīng)的路徑或字符串。

經(jīng)歷上述腳本后, 就會(huì)在指定的exportPath路徑下生成.ipa文件。我們一般是要將ipa和dSYM文件copy到指定的文件夾供測(cè)試去取, 后面便是一段處理繁瑣的路徑的腳本, 腳本本身沒(méi)任何難度, 但是要格外注意, 切測(cè)試起來(lái)需要花費(fèi)一定的時(shí)間, 如果使用fastlane就可以避免這個(gè)煩惱。

總結(jié)

本文主要是團(tuán)隊(duì)中的一次分享后的整理, 并不是特別細(xì)致的教程, 只是對(duì)當(dāng)下的自動(dòng)化打包的一些嘗試及過(guò)程中遇到的一些問(wèn)題和自己的一點(diǎn)思考, 如果有說(shuō)的不對(duì)的地方, 望不吝賜教。