使用Jenkins自動化構建Android和iOS應用

背景

隨著業務需求的演進，工程的復雜度會逐漸增加，自動化的踐行日益強烈。事實上，工程的自動化一直是我們努力的目標，能有效提高我們的生產效率，最大化減少人為出錯的概率，實現一些復雜的業務需求應變。
場景如下，公司現在的測試人員每次需要測試新版本，都需要開發人員打包，放到ftp，測試人員然後從ftp上拷貝到本地（或者用手機的ES文件管理器），再安裝。尤其臨近發版的一周，幾乎每天都要新版本。這樣的話，有兩方面的影響：第一，打斷了開發人員的開發進度；第二，開發人員打包效率低下，尤其是ios，不順的話，總是打的不對（可能是證書的問題）。
要解決這個問題，必須實現移動端應用的自動化構建。具體說來就是，使用持續集成（CI）系統jenkins，自動檢測並拉取最新代碼，自動打包Android的apk和ios的ipa，自動上傳到內測分發平台蒲公英上。（接下來，測試人員只要打開一個（或多個）固定的網址，掃描一下二維碼，就能下載最新的版本了…）

環境

因為要編譯ios，所以選擇Mac OSX 10.11.1。
無論是哪個操作系統，jenkins的配置是一樣的。

安裝Jenkins

官網地址：http://jenkins-ci.org/

1
2
3
4

// 使用brew安裝
brew install jenkins
// 啟動，直接運行jenkins即可啟動服務
jenkins

 

默認訪問http://localhost:8080/, 可進入jenkins配置頁面。

安裝Jenkins相關插件

點擊系統管理>管理插件>可選插件，可搜索以下插件安裝

git插件(GIT plugin)
ssh插件(SSH Credentials Plugin)
Gradle插件(Gradle plugin) - android專用
Xcode插件(Xcode integration) - ios專用

新建Job

主頁面，新建 -> 構建一個自由風格的軟件項目即可。
對於類似的項目，可以選擇 -> 復制已有的Item，要復制的任務名稱裡輸入其他job的首字符會有智能提示。

配置git倉庫

如果安裝了git插件，在源碼管理會出現Git，選中之後：
Repositories -> https://github.com/openproject/ganchai, 如果是ssh還要配置Credentials。
Branch -> */master，選定一個要編譯的分支代碼。
如下：

如果是私有的倉庫（比如git://xxxxx.git）,點擊Credentials - Add，彈出對話框，配置sshkey最簡單了：

配置自動拉取最新代碼

在構建觸發器中，有兩種自動拉取代碼並編譯的策略:

1. 設置Poll SCM，設置定時器，定時檢查代碼更新，有更新則編譯，否則不編譯（我暫時用的是這個）。
   
2. 也可以設置Build periodically，周期性的執行編譯任務。
   

關於定時器的格式，我只能從網上摘抄一段稍微靠譜一點的說明：

This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:

MINUTE HOUR DOM MONTH DOW

MINUTE Minutes within the hour (0-59)
HOUR The hour of the day (0-23)
DOM The day of the month (1-31)
MONTH The month (1-12)
DOW The day of the week (0-7) where 0 and 7 are Sunday.

To specify multiple values for one field, the following operators are available. In the order of precedence,

   * '*' can be used to specify all valid values.
   * 'M-N' can be used to specify a range, such as "1-5"
   * 'M-N/X' or '*/X' can be used to specify skips of X''s value through the range, such as "*/15" in the MINUTE field for "0,15,30,45" and "1-6/2" for "1,3,5"
   * 'A,B,...,Z' can be used to specify multiple values, such as "0,30" or "1,3,5"

Empty lines and lines that start with '#' will be ignored as comments.
In addition, @yearly, @annually, @monthly, @weekly, @daily, @midnight, @hourly are supported.

舉兩個例子：

1
2
3
4

// every minute
* * * * *
// every 5 mins past the hour
5 * * * *

 

配置gradle - android專用

請ios的朋友們請飄過.
如果安裝gradle插件成功的話，應該會出現下圖的Invoke Gradle script，配置一下:

${WORKSPACE}表示當前job下的workspace目錄，主要是存放代碼。更多的環境變量請參考文末附錄。
這樣，就能自動在project下的app的build/outputs/apk下生成相應的apk.
編譯失敗？可能要解決以下2個問題：

1. gradle沒配置環境變量。
   比如我在/etc/profile中配置一下GRADLE_HOME:

   1
   2

   export GRADLE_HOME='/home/jay/.gradle/wrapper/dists/gradle-2.2.1-all/c64ydeuardnfqctvr1gm30w53/gradle-2.2.1'
   export PATH=$GRADLE_HOME/bin:$PATH

2. 找不到local.properties中sdk定義。
   因為一般來說local.properties不會添加到版本庫。
   所以需要手動copy到${WORKSPACE}下的Project目錄下（可參考自己Android Studio工程結構）。
   關於local.properties的定義，這裡記錄一下，做個備份：

   1

   sdk.dir=xx/xx/android-sdk

再編譯一般就會編譯成功，當然當那些第三方庫需要重新下載的話，編譯可能會很慢。

配置xcode - ios專用

請android的同學們飄過。
安裝Xcode插件後，可看到如下圖界面，並配置：

這裡有兩個地方需要注意。

1. 簽名
2. 需要Shared Schema文件.

上傳到蒲公英平台

在官網文檔裡有說明，通過linux平台上傳app的關鍵代碼

1

curl -F "file=@/tmp/example.ipa" -F "uKey=" -F "_api_key=" http://www.pgyer.com/apiv1/app/upload

 

具體來說，

1
2

# 先把${version}看成v1.0吧
curl -F "file=@/home/xxx/release/ganchai-release-${version}-0101-dev.apk" -F "uKey=231xxxxe6" -F "_api_key=0xxxx499" -F "publishRange=2" http://www.pgyer.com/apiv1/app/upload

 

這樣就完成一個app上傳到蒲公英了。

實際上，我們可能會面對更復雜的場景，比如上面的${version}, 而version定義於build.gradle如下：

1
2
3
4
5
6
7
8

ext {
    compileSdkVersion = 22
    buildToolsVersion = "23.0.1"
    minSdkVersion = 10
    targetSdkVersion = 22
    versionCode = 1111
    versionName = "v1.2.0.0"
}

 

得想辦法讀到versionName, 然後拼出最終的文件名，這樣下次版本升級了之後也能動態的上傳app到蒲公英了。

1
2

# 使用sed命令讀取，使用cut切割，最終動態讀取到versionName
version=`sed -n '21,1p' ${WORKSPACE}/xxx/build.gradle | cut -c20-27`

 

這是android的apk上傳過程，相應的，ios是上傳ipa，方法是一樣的，不再贅述。

小結

把開發人員發布版本的工作自動化之後，如此一來，方便了測試人員隨時拉取並構建最新版本，更解放了開發人員自己的發版本的工作，一個字，善！

附錄

jenkins中定義的那些環境變量：

The following variables are available to shell scripts

BUILD_NUMBER
The current build number, such as "153"
BUILD_ID
The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)
BUILD_DISPLAY_NAME
The display name of the current build, which is something like "#153" by default.
JOB_NAME
Name of the project of this build, such as "foo" or "foo/bar". (To strip off folder paths from a Bourne shell script, try: ${JOB_NAME##*/})
BUILD_TAG
String of "jenkins-${JOB_NAME}-${BUILD_NUMBER}". Convenient to put into a resource file, a jar file, etc for easier identification.
EXECUTOR_NUMBER
The unique number that identifies the current executor (among executors of the same machine) that’s carrying out this build. This is the number you see in the "build executor status", except that the number starts from 0, not 1.
NODE_NAME
Name of the slave if the build is on a slave, or "master" if run on master
NODE_LABELS
Whitespace-separated list of labels that the node is assigned.
WORKSPACE
The absolute path of the directory assigned to the build as a workspace.
JENKINS_HOME
The absolute path of the directory assigned on the master node for Jenkins to store data.
JENKINS_URL
Full URL of Jenkins, like http://server:port/jenkins/ (note: only available if Jenkins URL set in system configuration)
BUILD_URL
Full URL of this build, like http://server:port/jenkins/job/foo/15/ (Jenkins URL must be set)
JOB_URL
Full URL of this job, like http://server:port/jenkins/job/foo/ (Jenkins URL must be set)
SVN_REVISION
Subversion revision number that's currently checked out to the workspace, such as "12345"
SVN_URL
Subversion URL that's currently checked out to the workspace.

Jenkins的分布式構建及部署——節點  http://www.linuxidc.com/Linux/2015-05/116903.htm

Jenkins 的詳細介紹：請點這裡
Jenkins 的下載地址：請點這裡