持續化集成工具Jenkins

時間 2019-11-18

原文原文鏈接

衆所周知，如今App的競爭已經到了用戶體驗爲王，質量爲上的白熱化階段。用戶們都是很挑剔的。若是一個公司的推廣團隊好不容易砸了重金推廣了一個APP，好不容易有了一些用戶，因爲一次線上的bug致使一批的用戶在使用中紛紛出現閃退bug，輕則，極可能前期推廣砸的錢都白費了，重則，口碑很差，將來也提高不起用戶量來了。靜下心來分析一下問題的緣由，無外乎就是質量沒有過關就上線了。除去主觀的一些因素，很大部分的客觀因素我以爲能夠被咱們防範的。根據大神們提出的一套開發規範建議，CI + FDD，就能夠幫助咱們極大程度的解決客觀因素。本文接下來主要討論 Continuous Integration 持續集成（簡稱CI）html

目錄java

1.爲何咱們須要持續集成android

2.持續化集成工具——Jenkinsios

3.iOS自動化打包命令——xcodebuild + xcrun 和 fastlane - gym 命令git

4.打包完成自動化上傳 fir / 蒲公英第三方平臺github

5.完整的持續集成流程docker

6.Jenkins + Dockerapi

1、爲何咱們須要持續集成xcode

談到爲何須要的問題，咱們就須要從什麼是來講起。那什麼是持續集成呢。瀏覽器

持續集成是一種軟件開發實踐：許多團隊頻繁地集成他們的工做，每位成員一般進行平常集成，進而天天會有多種集成。每一個集成會由自動的構建（包括測試）來儘量快地檢測錯誤。許多團隊發現這種方法能夠顯著的減小集成問題而且可使團隊開發更加快捷。

CI是一種開發實踐。實踐應該包含3個基本模塊，一個能夠自動構建的過程，自動編譯代碼，能夠自動分發，部署和測試。一個代碼倉庫，SVN或者Git。最後一個是一個持續集成的服務器。經過持續集成，可讓咱們經過自動化等手段高頻率地去獲取產品反饋並響應反饋的過程。

那麼持續集成能給咱們帶來些什麼好處呢？這裏推薦一篇文章，文章中把Continuous integration (CI) and test-driven development (TDD)分紅了12個步驟。然而帶來的好處成倍增長，有24點好處。

我來講說用了CI之後帶來的一些深有體會的優勢。

1. 縮減開發週期，快速迭代版本

每一個版本開始都會估算好開發週期，可是總會由於各類事情而延期。這其中包括了一些客觀因素。因爲產品線增多，迭代速度愈來愈快，給測試帶來的壓力也愈來愈大。若是測試都在開發徹底開發完成以後再來測試，那就會影響很長一段時間。這時候因爲集成晚就會嚴重拖慢項目節奏。若是能儘早的持續集成，儘快進入上圖的12步驟的迭代環中，就能夠儘早的暴露出問題，提前解決，儘可能在規定時間內完成任務。

2. 自動化流水線操做帶來的高效

其實打包對於開發人員來講是一件很耗時，並且沒有很大技術含量的工做。若是開發人員一多，相互改的代碼衝突的概率就越大，加上沒有產線管理機制，代碼倉庫的代碼質量很難保證。團隊裏面會花一些時間來解決衝突，解決完了衝突還須要本身手動打包。這個時候若是證書又不對，又要耽誤好長時間。這些時間其實能夠用持續集成來節約起來的。一天兩天看着很少，可是按照年的單位來計算，能夠節約不少時間！

3. 隨時可部署

有了持續集成之後，咱們能夠以天爲單位來打包，這種高頻率的集成帶來的最大的優勢就是能夠隨時部署上線。這樣就不會致使快要上線，處處是漏洞，處處是bug，手忙腳亂弄完之後還不能部署，嚴重影響上線時間。

4. 極大程度避免低級錯誤

咱們能夠犯錯誤，可是犯低級錯誤就很不該該。這裏指的低級錯誤包括如下幾點：編譯錯誤，安裝問題，接口問題，性能問題。

以天爲單位的持續集成，能夠很快發現編譯問題，自動打包直接沒法經過。打完包之後，測試掃碼沒法安裝，這種問題也會當即被暴露出來。接口問題和性能問題就有自動化測試腳原本發現。這些低級問題由持續集成來暴露展示出來，提醒咱們避免低級錯誤。

2、持續化集成工具——Jenkins

Jenkins 是一個開源項目，提供了一種易於使用的持續集成系統，使開發者從繁雜的集成中解脫出來，專一於更爲重要的業務邏輯實現上。同時 Jenkins 能實施監控集成中存在的錯誤，提供詳細的日誌文件和提醒功能，還能用圖表的形式形象地展現項目構建的趨勢和穩定性。

根據官方定義，Jenkins有如下的用途：

構建項目
跑測試用例檢測bug
靜態代碼檢測
部署

關於這4點，實際使用中仍是比較方便的：

1.構建項目自動化打包能夠省去開發人員好多時間，重要的是，Jenkins爲咱們維護了一套高質量可用的代碼，並且保證了一個純淨的環境。咱們常常會出現因爲本地配置出錯而致使打包失敗的狀況。如今Jenkins就是一個公平的評判者，它沒法正確的編譯出ipa，那就是有編譯錯誤或者配置問題。開發人員不必去爭論本地是能夠運行的，拉取了誰誰誰的代碼之後就不能運行了。共同維護Jenkins的正常編譯，由於Jenkins的編譯環境比咱們本地簡單的多，它是最純淨無污染的編譯環境。開發者就只用專一於編碼。這是給開發者帶來的便利。

2.這個能夠用來自動化測試。在本地生成大批的測試用例。天天利用服務器不斷的跑這些用例。天天每一個接口都跑一遍。看上去不必，可是實際上今天運行正常的系統，極可能因爲今天的代碼改動，明天就出現問題了。有了Jenkins能夠以天爲單位的進行迴歸測試，代碼只要有改動，Jenkins就把全部的迴歸測試的用例所有都跑一遍。在項目工期緊張的狀況下，不少狀況測試都不是很重視迴歸測試，畢竟極可能測一遍以後是徒勞的「無用功」。然而因爲迴歸測試不及時，就致使到最後發版的時候系統不可用了，這時候回頭查找緣由是比較耗時的，查看提交記錄，看到上百條提交記錄，排查起來也是頭疼的事情。以天爲單位的迴歸測試能當即發現問題。測試人員天天能夠專一按單元測試，一週手動一次迴歸測試。這是給測試者帶來的便利。

3.這個是靜態代碼分析，能夠檢測出不少代碼的問題，好比潛在的內存泄露的問題。因爲Jenkins所在環境的純淨，仍是能夠發現一些咱們本地複雜環境沒法發現的問題，進一步的提升代碼質量。這是給質檢帶來的便利。

4.隨時部署。Jenkins在打包完成以後能夠設定以後的操做，這個時候每每就是提交app到跑測試用例的系統，或者部署到內測平臺生成二維碼。部署中不能安裝等一些低級問題隨之當即暴露。測試人員也只須要掃一下二維碼便可安裝，很方便。這也算是給測試帶來的便利。

如下的例子以2016-07-24 22:35的Weekly Release 2.15的版本爲例。

咱們來開始安裝Jenkins。從官網https://jenkins.io/ 上下載最新的pkg安裝包。

也能夠下載jenkins.war, 而後運行Java -jar jenkins.war，進行安裝。

安裝完成以後，Safari可能會自動打開，若是沒有自動打開，打開瀏覽器，輸入http://localhost:8080

這個時候可能會報一個錯誤。若是出現了這面的問題。出現這個問題的緣由就是Java環境有問題，從新Java環境便可。

這個時候若是你重啓電腦會發現Jenkins給你新增了一個用戶，名字就叫Jenkins，不過這個時候你不知道密碼。你可能會去試密碼，確定是是不對的，由於初始密碼很複雜。這個時候正確作法是打開http://localhost:8080 會出現下圖的重設初始密碼的界面。

按照提示，找到/Users/Shared/Jenkins/Home/ 這個目錄下，這個目錄雖然是共享目錄，可是有權限的，非Jenkins用戶/secrets/目錄是沒有讀寫權限的。

打開initialAdminPassword文件，複製出密碼，就能夠填到網頁上去重置密碼了。以下圖

一路安裝過來，輸入用戶名，密碼，郵件這些，就算安裝完成了。

仍是繼續登陸localhost:8080 ，選擇「系統管理」——「管理插件」，咱們要先安裝一些輔助插件。

安裝GitLab插件

由於咱們用的是GitLab來管理源代碼，Jenkins自己並無自帶GitLab插件，因此咱們須要依次選擇系統管理->管理插件，在「可選插件」中選中「GitLab Plugin」和「Gitlab Hook Plugin」這兩項，而後安裝。

安裝Xcode插件

同安裝GitLab插件的步驟同樣，咱們依次選擇系統管理->管理插件，在「可選插件」中選中「Xcode integration」安裝。

安裝完了這個，咱們就能夠配置一個構建項目了。

點擊新建好的項目，進來配置一下General參數。

這裏能夠設置包的保留天數還有天數。

接着設置源碼管理。

因爲如今我用到的是GitLab，先配置SSH Key，在Jenkins的證書管理中添加SSH。在Jenkins管理頁面，選擇「Credentials」，而後選擇「Global credentials (unrestricted)」，點擊「Add Credentials」，以下圖所示，咱們填寫本身的SSH信息，而後點擊「Save」，這樣就把SSH添加到Jenkins的全局域中去了。

若是正常的配置正確的話，是不會出現下圖中的那段紅色的警告。若是有下圖的提示，就說明Jenkins尚未連通GitLab或者SVN，那就請再檢查SSH Key是否配置正確。

構建觸發器設置這裏是設置自動化測試的地方。這裏涉及的內容不少，暫時我也沒有深刻研究，這裏暫時先不設置。有自動化測試需求的能夠好好研究研究這裏的設置。

不過這裏有兩個配置仍是須要是配置的

Poll SCM (poll source code management) 輪詢源碼管理

須要設置源碼的路徑才能起到輪詢的效果。通常設置爲相似結果： 0/5 每5分鐘輪詢一次

Build periodically (定時build)

通常設置爲相似： 00 20 * 天天 20點執行定時build 。固然二者的設置都是同樣能夠通用的。

格式是這樣的

分鐘(0-59) 小時(0-23) 日期(1-31) 月(1-12) 周幾(0-7,0和7都是週日)（更加詳細的設置看這裏）

構建環境設置

iOS打包須要簽名文件和證書，因此這部分咱們勾選「Keychains and Code Signing Identities」和「Mobile Provisioning Profiles」。

這裏咱們又須要用到Jenkins的插件，在系統管理頁面，選擇「Keychains and Provisioning Profiles Management」。

進入Keychains and Provisioning Profiles Management頁面，點擊「瀏覽」按鈕，分別上傳本身的keychain和證書。上傳成功後，咱們再爲keychain指明簽名文件的名稱。點擊「Add Code Signing Identity」，最後添加成功後以下圖所示：

注意：我第一次導入證書和Provisioning Profiles文件，就遇到了一點小「坑」，我當時覺得是須要證書，可是這裏須要的Keychain，並非cer證書文件。這個Keychain其實在/Users/管理員用戶名/Library/keychains/login.keychain,當把這個Keychain設置好了以後，Jenkins會把這個Keychain拷貝到/Users/Shared/Jenkins/Library/keychains這裏，(Library是隱藏文件)。Provisioning Profiles文件也直接拷貝到/Users/Shared/Jenkins/Library/MobileDevice文件目錄下。

這樣Adhoc證書和簽名文件就在Jenkins中配置好了，接下來咱們只須要在item設置中指定相關文件便可。

回到咱們新建的item，找到構建環境，按下圖選好本身的相關證書和簽名文件。

接下來在進行構建的設置

咱們這裏選擇執行一段打包腳本。腳本在下一章節詳細的講解。

構建後操做

這裏咱們選擇Execute a set of scripts，這裏也是一個腳本，這個腳本用來上傳自動打包好的ipa文件。腳本在第四章節有詳細的講解。

至此，咱們的Jenkins設置就所有完成了。點擊構建，就會開始構建項目了。

構建一次，各個顏色表明的意義以下：

天氣的晴雨表表明了項目的質量，這也是Jenkins的一個特點。

若是構建失敗了，能夠去查看Console Output能夠查看log日誌。

3、iOS自動化打包命令——xcodebuild + xcrun 和 fastlane - gym 命令

在平常開發中，打包是最後上線不可缺乏的環節，若是須要把工程打包成 ipa 文件，一般的作法就是在 Xcode 裏點擊「Product -> Archive」，當整個工程 archive 後，而後在自動彈出的「Organizer」中進行選擇，根據須要導出 ad hoc，enterprise 類型的 ipa 包。雖然Xcode已經能夠很完美的作到打包的事情，可是仍是須要咱們手動點擊5，6下。加上咱們如今須要持續集成，用打包命令自動化執行就順其天然的須要了。

1. xcodebuild + xcrun命令

Xcode爲咱們開發者提供了一套構建打包的命令，就是xcodebuild

和xcrun命令。xcodebuild把咱們指定的項目打包成.app文件，xcrun將指定的.app文件轉換爲對應的.ipa文件。

具體的文檔以下：xcodebuild官方文檔、xcrun官方文檔

NAME

xcodebuild – build Xcode projects and workspaces

SYNOPSIS

1. xcodebuild [-project name.xcodeproj] [[-target targetname] … | -alltargets] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …]

2. xcodebuild [-project name.xcodeproj] -scheme schemename [[-destination destinationspecifier] …] [-destination-timeout value] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …]

3. xcodebuild -workspace name.xcworkspace -scheme schemename [[-destination destinationspecifier] …] [-destination-timeout value] [-configuration configurationname] [-sdk [sdkfullpath | sdkname]] [action …] [buildsetting=value …] [-userdefault=value …]

4. xcodebuild -version [-sdk [sdkfullpath | sdkname]] [infoitem]

5. xcodebuild -showsdks

6. xcodebuild -showBuildSettings [-project name.xcodeproj | [-workspace name.xcworkspace -scheme schemename]]

7. xcodebuild -list [-project name.xcodeproj | -workspace name.xcworkspace]

8. xcodebuild -exportArchive -archivePath xcarchivepath -exportPath destinationpath -exportOptionsPlist path

9. xcodebuild -exportLocalizations -project name.xcodeproj -localizationPath path [[-exportLanguage language] …]

10. xcodebuild -importLocalizations -project name.xcodeproj -localizationPath path

上面10個命令最主要的仍是前3個。

接下來來講明一下參數：

-project -workspace：這兩個對應的就是項目的名字。若是有多個工程，這裏又沒有指定，則默認爲第一個工程。

-target：打包對應的targets，若是沒有指定這默認第一個。

-configuration：若是沒有修改這個配置，默認就是Debug和Release這兩個版本，沒有指定默認爲Release版本。

-buildsetting=value ...：使用此命令去修改工程的配置。

-scheme：指定打包的scheme。

上面這些是最最基本的命令。

上面10個命令的第一個和第二個裏面的參數，其中 -target

和 -configuration 參數可使用 xcodebuild -list

得到，-sdk 參數可由 xcodebuild -showsdks

得到，[buildsetting=value ...] 用來覆蓋工程中已有的配置。可覆蓋的參數參考官方文檔：Xcode Build Setting Reference。

build

Build the target in the build root (SYMROOT). This is the default action, and is used if no action is given.

analyze

Build and analyze a target or scheme from the build root (SYMROOT). This requires specifying a scheme.

archive

Archive a scheme from the build root (SYMROOT). This requires specifying a scheme.

test

Test a scheme from the build root (SYMROOT). This requires specifying a scheme and optionally a destination.

installsrc

Copy the source of the project to the source root (SRCROOT).

install

Build the target and install it into the target’s installation directory in the distribution root (DSTROOT).

clean

Remove build products and intermediate files from the build root (SYMROOT).

上面第3個命令就是專門用來打帶有Cocopods的項目，由於這個時候項目工程文件再也不是xcodeproj了，而是變成了xcworkspace了。

再來講說xcrun命令。

Usage:

PackageApplication [-s signature] application [-o output_directory] [-verbose] [-plugin plugin] || -man || -help

Options:

[-s signature]: certificate name to resign application before packaging

[-o output_directory]: specify output filename

[-plugin plugin]: specify an optional plugin

-help: brief help message

-man: full documentation

-v[erbose]: provide details during operation

參數很少，使用方法也很簡單，xcrun -sdk iphoneos -v PackageApplication + 上述一些參數。

參數都瞭解以後，咱們就來看看該如何用了。下面這個是使用了xcodebuild + xcrun命令寫的自動化打包腳本

# 工程名

APP_NAME="YourProjectName"

# 證書

CODE_SIGN_DISTRIBUTION="iPhone Distribution: Shanghai ******* Co., Ltd."

# info.plist路徑

project_infoplist_path="./${APP_NAME}/Info.plist"

#取版本號

bundleShortVersion=$(/usr/libexec/PlistBuddy -c "print CFBundleShortVersionString" "${project_infoplist_path}")

#取build值

bundleVersion=$(/usr/libexec/PlistBuddy -c "print CFBundleVersion" "${project_infoplist_path}")

DATE="$(date +%Y%m%d)"

IPANAME="${APP_NAME}_V${bundleShortVersion}_${DATE}.ipa"

#要上傳的ipa文件路徑

IPA_PATH="$HOME/${IPANAME}"

echo ${IPA_PATH}

echo "${IPA_PATH}">> text.txt

//下面2行是沒有Cocopods的用法

echo "=================clean================="

xcodebuild -target "${APP_NAME}" -configuration 'Release' clean

echo "+++++++++++++++++build+++++++++++++++++"

xcodebuild -target "${APP_NAME}" -sdk iphoneos -configuration 'Release' CODE_SIGN_IDENTITY="${CODE_SIGN_DISTRIBUTION}" SYMROOT='$(PWD)'

//下面2行是集成有Cocopods的用法

echo "=================clean================="

xcodebuild -workspace "${APP_NAME}.xcworkspace" -scheme "${APP_NAME}" -configuration 'Release' clean

echo "+++++++++++++++++build+++++++++++++++++"

xcodebuild -workspace "${APP_NAME}.xcworkspace" -scheme "${APP_NAME}" -sdk iphoneos -configuration 'Release' CODE_SIGN_IDENTITY="${CODE_SIGN_DISTRIBUTION}" SYMROOT='$(PWD)'

xcrun -sdk iphoneos PackageApplication "./Release-iphoneos/${APP_NAME}.app" -o ~/"${IPANAME}"

2. gym 命令

說到gym，就要先說一下fastlane。

fastlane是一套自動化打包的工具集，用 Ruby 寫的，用於 iOS 和 Android 的自動化打包和發佈等工做。gym是其中的打包命令。

fastlane的官網看這裏, fastlane的github看這裏。

要想使用gym，先要安裝fastlane。

1	`sudo gem install fastlane --verbose`

fastlane包含了咱們平常編碼以後要上線時候進行操做的全部命令。
deliver：上傳屏幕截圖、二進制程序數據和應用程序到AppStore
snapshot：自動截取你的程序在每一個設備上的圖片
frameit：應用截屏外添加設備框架
pem：能夠自動化地生成和更新應用推送通知描述文件
sigh：生成下載開發商店的配置文件
produce：利用命令行在iTunes Connect建立一個新的iOS app
cert：自動建立iOS證書
pilot：最好的在終端管理測試和創建的文件
boarding：很容易的方式邀請beta測試
gym：創建新的發佈的版本，打包
match：使用git同步你成員間的開發者證書和文件配置
scan：在iOS和Mac app上執行測試用例

整個發佈過程能夠用fastlane描述成下面這樣

lane :appstore do

increment_build_number

cocoapods

xctool

snapshot

sigh

deliver

frameit

sh "./customScript.sh"

slack

end

Ps：這裏可能你們還會聽過一個命令叫 xctool

xctool是官方xcodebuild命令的一個加強實現，輸出的內容比xcodebuild直觀可讀得多。經過brew便可安裝。

1	`brew install xctool`

使用gym自動化打包，腳本以下：

#計時

SECONDS=0

#假設腳本放置在與項目相同的路徑下

project_path=$(pwd)

#取當前時間字符串添加到文件結尾

now=$(date +"%Y_%m_%d_%H_%M_%S")

#指定項目的scheme名稱

scheme="DemoScheme"

#指定要打包的配置名

configuration="Adhoc"

#指定打包所使用的輸出方式，目前支持app-store, package, ad-hoc, enterprise, development, 和developer-id，即xcodebuild的method參數

export_method='ad-hoc'

#指定項目地址

workspace_path="$project_path/Demo.xcworkspace"

#指定輸出路徑

output_path="/Users/your_username/Documents/"

#指定輸出歸檔文件地址

archive_path="$output_path/Demo_${now}.xcarchive"

#指定輸出ipa地址

ipa_path="$output_path/Demo_${now}.ipa"

#指定輸出ipa名稱

ipa_name="Demo_${now}.ipa"

#獲取執行命令時的commit message

commit_msg="$1"

#輸出設定的變量值

echo "===workspace path: ${workspace_path}==="

echo "===archive path: ${archive_path}==="

echo "===ipa path: ${ipa_path}==="

echo "===export method: ${export_method}==="

echo "===commit msg: $1==="

#先清空前一次build

gym --workspace ${workspace_path} --scheme ${scheme} --clean --configuration ${configuration} --archive_path ${archive_path} --export_method ${export_method} --output_directory ${output_path} --output_name ${ipa_name}

#輸出總用時

echo "===Finished. Total time: ${SECONDS}s==="

4、打包完成自動化上傳 fir / 蒲公英第三方平臺

要上傳到 fir / 蒲公英第三方平臺，都須要註冊一個帳號，得到token，以後才能進行腳本化操做。

1. 自動化上傳fir

安裝fir-clifir的命令行工具

須要先裝好ruby再執行

gem install fir-cli

#上傳到fir

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

2.自動化上傳蒲公英

#蒲公英上的User Key

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

#蒲公英上的API Key

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

#要上傳的ipa文件路徑

IPA_PATH=$(cat text.txt)

rm -rf text.txt

#執行上傳至蒲公英的命令

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

curl -F "file=@${IPA_PATH}" -F "uKey=${uKey}" -F "_api_key=${apiKey}" http://www.pgyer.com/apiv1/app/upload

5、完整的持續集成流程

通過上面的持續化集成，如今咱們就擁有了以下完整持續集成的流程

6、Jenkins + Docker

關於Jenkins的部署，實際上是分如下兩種：

單節點（Master）部署

這種部署適用於大多數項目，其構建任務較輕，數量較少，單個節點就足以知足平常開發所需。

多節點(Master-Slave)部署

一般規模較大，代碼提交頻繁（意味着構建頻繁），自動化測試壓力較大的項目都會採起這種部署結構。在這種部署結構下，Master一般只充當管理者的角色，負責任務的調度，slave節點的管理，任務狀態的收集等工做，而具體的構建任務則會分配給slave節點。一個Master節點理論上能夠管理的slave節點數是沒有上限的，但一般隨着數量的增長，其性能以及穩定性就會有不一樣程度的降低，具體的影響則因Master硬件性能的高低而不一樣。

可是多節點部署又會有一些缺陷，當測試用例變得海量之後，會形成一些問題，因而有人設計出了下面這種部署結構，Jenkins + Docker

因爲筆者如今的項目還處於單節點（Master）部署，關於多節點(Master-Slave)部署也沒有實踐經驗，改進版本的Docker更是沒有接觸過，可是若是有這種海量測試用例，高壓力的大量複雜的迴歸測試的需求的，那推薦你們看這篇文章。