www..插插插,激情中文网

iOS 腳本自動(dòng)化打包

1.為什么需要持續(xù)集成（Continuous Integration）CI

2.持續(xù)化集成工具——Jenkins

3.iOS自動(dòng)化打包命令——xcodebuild + xcrun 和 fastlane – gym 命令 (Fastlane 2.38 發(fā)布，首次支持 Xcode 9)

4.打包完成自動(dòng)化上傳 fir / 蒲公英第三方平臺(tái)

5.完整的持續(xù)集成流程

6.Jenkins + Docker

7.自動(dòng)化測(cè)試

Jenkins 上完成基于 KIF 的 UI 自動(dòng)化持續(xù)集成搭建

一、持續(xù)集成

CI是一種開發(fā)實(shí)踐。實(shí)踐應(yīng)該包含3個(gè)基本模塊，一個(gè)可以自動(dòng)構(gòu)建的過程，自動(dòng)編譯代碼，可以自動(dòng)分發(fā)，部署和測(cè)試。一個(gè)代碼倉庫，SVN或者Git。最后一個(gè)是一個(gè)持續(xù)集成的服務(wù)器。通過持續(xù)集成，可以讓我們通過自動(dòng)化等手段高頻率地去獲取產(chǎn)品反饋并響應(yīng)反饋的過程。

那么持續(xù)集成能給我們帶來些什么好處呢？這里推薦一篇文章，文章中把Continuous integration(CI) andtest-driven development(TDD)分成了12個(gè)步驟。然而帶來的好處成倍增加，有24點(diǎn)好處。

優(yōu)點(diǎn)

1. 縮減開發(fā)周期，快速迭代版本

每個(gè)版本開始都會(huì)估算好開發(fā)周期，但是總會(huì)因?yàn)楦鞣N事情而延期。這其中包括了一些客觀因素。由于產(chǎn)品線增多，迭代速度越來越快，給測(cè)試帶來的壓力也越來越大。如果測(cè)試都在開發(fā)完全開發(fā)完成之后再來測(cè)試，那就會(huì)影響很長(zhǎng)一段時(shí)間。這時(shí)候由于集成晚就會(huì)嚴(yán)重拖慢項(xiàng)目節(jié)奏。如果能盡早的持續(xù)集成，盡快進(jìn)入上圖的12步驟的迭代環(huán)中，就可以盡早的暴露出問題，提早解決，盡量在規(guī)定時(shí)間內(nèi)完成任務(wù)。

2. 自動(dòng)化流水線操作帶來的高效

其實(shí)打包對(duì)于開發(fā)人員來說是一件很耗時(shí)，而且沒有很大技術(shù)含量的工作。如果開發(fā)人員一多，相互改的代碼沖突的幾率就越大，加上沒有產(chǎn)線管理機(jī)制，代碼倉庫的代碼質(zhì)量很難保證。團(tuán)隊(duì)里面會(huì)花一些時(shí)間來解決沖突，解決完了沖突還需要自己手動(dòng)打包。這個(gè)時(shí)候如果證書又不對(duì)，又要耽誤好長(zhǎng)時(shí)間。這些時(shí)間其實(shí)可以用持續(xù)集成來節(jié)約起來的。一天兩天看著不多，但是按照年的單位來計(jì)算，可以節(jié)約很多時(shí)間！

3. 隨時(shí)可部署

有了持續(xù)集成以后，我們可以以天為單位來打包，這種高頻率的集成帶來的最大的優(yōu)點(diǎn)就是可以隨時(shí)部署上線。這樣就不會(huì)導(dǎo)致快要上線，到處是漏洞，到處是bug，手忙腳亂弄完以后還不能部署，嚴(yán)重影響上線時(shí)間。

4. 極大程度避免低級(jí)錯(cuò)誤

我們可以犯錯(cuò)誤，但是犯低級(jí)錯(cuò)誤就很不應(yīng)該。這里指的低級(jí)錯(cuò)誤包括以下幾點(diǎn)：編譯錯(cuò)誤，安裝問題，接口問題，性能問題。

以天為單位的持續(xù)集成，可以很快發(fā)現(xiàn)編譯問題，自動(dòng)打包直接無法通過。打完包以后，測(cè)試掃碼無法安裝，這種問題也會(huì)立即被暴露出來。接口問題和性能問題就有自動(dòng)化測(cè)試腳本來發(fā)現(xiàn)。這些低級(jí)問題由持續(xù)集成來暴露展現(xiàn)出來，提醒我們避免低級(jí)錯(cuò)誤。

二、jenkins

Jenkins 是一個(gè)開源項(xiàng)目，提供了一種易于使用的持續(xù)集成系統(tǒng)，使開發(fā)者從繁雜的集成中解脫出來，專注于更為重要的業(yè)務(wù)邏輯實(shí)現(xiàn)上。同時(shí) Jenkins 能實(shí)施監(jiān)控集成中存在的錯(cuò)誤，提供詳細(xì)的日志文件和提醒功能，還能用圖表的形式形象地展示項(xiàng)目構(gòu)建的趨勢(shì)和穩(wěn)定性。

根據(jù)官方定義，Jenkins有以下的用途：

構(gòu)建項(xiàng)目

跑測(cè)試用例檢測(cè)bug

靜態(tài)代碼檢測(cè)

部署

關(guān)于這4點(diǎn)，實(shí)際使用中還是比較方便的：

1.構(gòu)建項(xiàng)目自動(dòng)化打包可以省去開發(fā)人員好多時(shí)間，重要的是，Jenkins為我們維護(hù)了一套高質(zhì)量可用的代碼，而且保證了一個(gè)純凈的環(huán)境。我們經(jīng)常會(huì)出現(xiàn)由于本地配置出錯(cuò)而導(dǎo)致打包失敗的情況。現(xiàn)在Jenkins就是一個(gè)公平的評(píng)判者，它無法正確的編譯出ipa，那就是有編譯錯(cuò)誤或者配置問題。開發(fā)人員沒必要去爭(zhēng)論本地是可以運(yùn)行的，拉取了誰誰誰的代碼以后就不能運(yùn)行了。共同維護(hù)Jenkins的正常編譯，因?yàn)镴enkins的編譯環(huán)境比我們本地簡(jiǎn)單的多，它是最純凈無污染的編譯環(huán)境。開發(fā)者就只用專注于編碼。這是給開發(fā)者帶來的便利。

2.這個(gè)可以用來自動(dòng)化測(cè)試。在本地生成大批的測(cè)試用例。每天利用服務(wù)器不斷的跑這些用例。每天每個(gè)接口都跑一遍。看上去沒必要，但是實(shí)際上今天運(yùn)行正常的系統(tǒng)，很可能由于今天的代碼改動(dòng)，明天就出現(xiàn)問題了。有了Jenkins可以以天為單位的進(jìn)行回歸測(cè)試，代碼只要有改動(dòng)，Jenkins就把所有的回歸測(cè)試的用例全部都跑一遍。在項(xiàng)目工期緊張的情況下，很多情況測(cè)試都不是很重視回歸測(cè)試，畢竟很可能測(cè)一遍之后是徒勞的“無用功”。然而由于回歸測(cè)試不及時(shí)，就導(dǎo)致到最后發(fā)版的時(shí)候系統(tǒng)不可用了，這時(shí)候回頭查找原因是比較耗時(shí)的，查看提交記錄，看到上百條提交記錄，排查起來也是頭疼的事情。以天為單位的回歸測(cè)試能立即發(fā)現(xiàn)問題。測(cè)試人員每天可以專注按單元測(cè)試，一周手動(dòng)一次回歸測(cè)試。這是給測(cè)試者帶來的便利。

3.這個(gè)是靜態(tài)代碼分析，可以檢測(cè)出很多代碼的問題，比如潛在的內(nèi)存泄露的問題。由于Jenkins所在環(huán)境的純凈，還是可以發(fā)現(xiàn)一些我們本地復(fù)雜環(huán)境無法發(fā)現(xiàn)的問題，進(jìn)一步的提高代碼質(zhì)量。這是給質(zhì)檢帶來的便利。

4.隨時(shí)部署。Jenkins在打包完成之后可以設(shè)定之后的操作，這個(gè)時(shí)候往往就是提交app到跑測(cè)試用例的系統(tǒng)，或者部署到內(nèi)測(cè)平臺(tái)生成二維碼。部署中不能安裝等一些低級(jí)問題隨之立即暴露。測(cè)試人員也只需要掃一下二維碼即可安裝，很方便。這也算是給測(cè)試帶來的便利。

Jenkins安裝方式(Mac)

前提：必須有java環(huán)境

1.直接下載安裝安裝---jenkins

2.通過Homebrew使用命令行安裝

（1）安裝Homebrew

ruby -e "$(curl -fsSLhttps://raw.githubusercontent.com/Homebrew/install/master/install)"

（2）安裝Jenkins

brew install jenkins

（3）啟動(dòng)Jenkins

jenkins

3.tomcat+jenkins（jenkins 運(yùn)行在tomcat上)

tomcat:必須得賦予一個(gè)用戶

localhost:8080/jenkins/

jenkins 默認(rèn)配置http://localhost:8080初次安裝進(jìn)入會(huì)有密碼提示路徑（查找路徑進(jìn)入，復(fù)制密碼填寫，進(jìn)入后建立一個(gè)用戶然后以新建的用戶進(jìn)行登陸）

sudo vim /var/root/.jenkins/secrets/initialAdminPassword

重啟服務(wù) java -jar jenkins.war --httpPort=8888

4.jenkins 插件(系統(tǒng)管理------>管理插件)

1、Xcode integration

2、GIT plugin

3、GitLab Plugin

4、Gitlab Hook Plugin

5、Keychains and Provisioning Profiles Management

6、CocoaPods Jenkins Integration

5.鑰匙串、配置文件管理（系統(tǒng)管理------>Keychains and Provisioning Profiles Management）

1.login.keychain??? 【位置? ~/Library/Keychains/login.keychain】

2.iPhone Developer 名稱

3.iPhone Distribution 名稱

4.本機(jī)配置文件路徑?? 【位置 /Users/<用戶名>/Library/MobileDevice/Provisioning Profiles】

5.打包測(cè)試包用的的配置文件ad_hoc

6.打包正式上線環(huán)境用到的配置文件distribution

注意：1、5、6 需要上傳文件然后upload

2、3 只需要把名稱填進(jìn)去就可以了（如下圖）

到此iOS 打包環(huán)境配置已經(jīng)完成

6.【jenkins iOS項(xiàng)目配置】

三、iOS自動(dòng)化打包命令

1.xcodebuild + xcrun

2.fastlane – gym??linGan_dev_ipa.sh(自己項(xiàng)目中用到的)

四、打包完成自動(dòng)化上傳fir/蒲公英第三方平臺(tái)

要上傳到 fir / 蒲公英第三方平臺(tái)，都需要注冊(cè)一個(gè)賬號(hào)，獲得token，之后才能進(jìn)行腳本化操作。

1. 自動(dòng)化上傳fir

安裝fir-clifir的命令行工具（需要先裝好ruby再執(zhí)行）

gem install fir-cli

#上傳到fir

fir publish ${ipa_path} -T fir_token -c "${commit_msg}"

2.自動(dòng)化上傳蒲公英

#蒲公英上的User Key

uKey="7381f97070*****c01fae439fb8b24e"

#蒲公英上的API Key

apiKey="0b27b5c145*****718508f2ad0409ef4"

#要上傳的ipa文件路徑

IPA_PATH=$(cat text.txt)

#執(zhí)行上傳至蒲公英的命令

echo "++++++++++++++upload+++++++++++++"

curl -F "file=@${IPA_PATH}" -F "uKey=${uKey}" -F "_api_key=${apiKey}"

五. 完整的持續(xù)集成流程

經(jīng)過上面的持續(xù)化集成，現(xiàn)在我們就擁有了如下完整持續(xù)集成的流程

六. Jenkins + Docker

關(guān)于Jenkins的部署，其實(shí)是分以下兩種：

單節(jié)點(diǎn)（Master）部署

這種部署適用于大多數(shù)項(xiàng)目，其構(gòu)建任務(wù)較輕，數(shù)量較少，單個(gè)節(jié)點(diǎn)就足以滿足日常開發(fā)所需。

多節(jié)點(diǎn)(Master-Slave)部署

通常規(guī)模較大，代碼提交頻繁（意味著構(gòu)建頻繁），自動(dòng)化測(cè)試壓力較大的項(xiàng)目都會(huì)采取這種部署結(jié)構(gòu)。在這種部署結(jié)構(gòu)下，Master通常只充當(dāng)管理者的角色，負(fù)責(zé)任務(wù)的調(diào)度，slave節(jié)點(diǎn)的管理，任務(wù)狀態(tài)的收集等工作，而具體的構(gòu)建任務(wù)則會(huì)分配給slave節(jié)點(diǎn)。一個(gè)Master節(jié)點(diǎn)理論上可以管理的slave節(jié)點(diǎn)數(shù)是沒有上限的，但通常隨著數(shù)量的增加，其性能以及穩(wěn)定性就會(huì)有不同程度的下降，具體的影響則因Master硬件性能的高低而不同。

但是多節(jié)點(diǎn)部署又會(huì)有一些缺陷，當(dāng)測(cè)試用例變得海量以后，會(huì)造成一些問題，于是有人設(shè)計(jì)出了下面這種部署結(jié)構(gòu)，Jenkins + Docker