背景
隨著業務需求的演進，工程的複雜度會逐漸增加，自動化的踐行日益強烈。事實上，工程的自動化一直是我們努力的目標，能有效提高我們的生產效率，最大化減少人為出錯的概率，實現一些複雜的業務需求應變。
場景如下，公司現在的測試人員每次需要測試新版本，都需要開發人員打包，放到ftp，測試人員然後從ftp上拷貝到本地（或者用手機的ES檔案管理器），再安裝。尤其臨近發版的一週，幾乎每天都要新版本。這樣的話，有兩方面的影響：第一，打斷了開發人員的開發進度；第二，開發人員打包效率低下，尤其是ios，不順的話，總是打的不對（可能是證照的問題）。
要解決這個問題，必須實現移動端應用的自動化構建。具體說來就是，使用持續整合（CI）系統jenkins，自動檢測並拉取最新程式碼，自動打包android的apk和ios的ipa，自動上傳到內測分發平臺蒲公英上。（接下來，測試人員只要開啟一個（或多個）固定的網址，掃描一下二維碼，就能下載最新的版本了…）
環境
因為要編譯ios，所以選擇Mac OSX 10.11.1。
無論是哪個作業系統，jenkins的配置是一樣的。
安裝Jenkins
|
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最簡單了：
配置自動拉取最新程式碼
在構建觸發器中，有兩種自動拉取程式碼並編譯的策略:
- 設定Poll SCM，設定定時器，定時檢查程式碼更新，有更新則編譯，否則不編譯（我暫時用的是這個）。
- 也可以設定Build periodically，週期性的執行編譯任務。
關於定時器的格式，我只能從網上摘抄一段稍微靠譜一點的說明：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
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個問題：
- gradle沒配置環境變數。
比如我在/etc/profile中配置一下GRADLE_HOME:12export GRADLE_HOME='/home/jay/.gradle/wrapper/dists/gradle-2.2.1-all/c64ydeuardnfqctvr1gm30w53/gradle-2.2.1'export PATH=$GRADLE_HOME/bin:$PATH
- 找不到local.properties中sdk定義。
因為一般來說local.properties不會新增到版本庫。
所以需要手動copy到${WORKSPACE}下的Project目錄下（可參考自己Android Studio工程結構）。
關於local.properties的定義，這裡記錄一下，做個備份：1sdk.dir=xx/xx/android-sdk
再編譯一般就會編譯成功，當然當那些第三方庫需要重新下載的話，編譯可能會很慢。
配置xcode – ios專用
請android的同學們飄過。
安裝Xcode外掛後，可看到如下圖介面，並配置：
這裡有兩個地方需要注意。
- 簽名
- 需要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中定義的那些環境變數：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
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. |