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

目錄

1.為什麼我們需要持續整合

2.持續化整合工具——Jenkins

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

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

5.完整的持續整合流程

6.Jenkins + Docker

一、為什麼我們需要持續整合

談到為什麼需要的問題，我們就需要從什麼是來說起。那什麼是持續整合呢。

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

CI是一種開發實踐。實踐應該包含3個基本模組，一個可以自動構建的過程，自動編譯程式碼，可以自動分發，部署和測試。一個程式碼倉庫，SVN或者Git。最後一個是一個持續整合的伺服器。通過持續整合，可以讓我們通過自動化等手段高頻率地去獲取產品反饋並響應反饋的過程。

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

我來說說用了CI以後帶來的一些深有體會的優點。

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

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

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

其實打包對於開發人員來說是一件很耗時，而且沒有很大技術含量的工作。如果開發人員一多，相互改的程式碼衝突的機率就越大，加上沒有產線管理機制，程式碼倉庫的程式碼質量很難保證。團隊裡面會花一些時間來解決衝突，解決完了衝突還需要自己手動打包。這個時候如果證書又不對，又要耽誤好長時間。這些時間其實可以用持續整合來節約起來的。一天兩天看著不多，但是按照年的單位來計算，可以節約很多時間！

3. 隨時可部署

有了持續整合以後，我們可以以天為單位來打包，這種高頻率的整合帶來的最大的優點就是可以隨時部署上線。這樣就不會導致快要上線，到處是漏洞，到處是bug，手忙腳亂弄完以後還不能部署，嚴重影響上線時間。

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

我們可以犯錯誤，但是犯低階錯誤就很不應該。這裡指的低階錯誤包括以下幾點：編譯錯誤，安裝問題，介面問題，效能問題。

以天為單位的持續整合，可以很快發現編譯問題，自動打包直接無法通過。打完包以後，測試掃碼無法安裝，這種問題也會立即被暴露出來。介面問題和效能問題就有自動化測試指令碼來發現。這些低階問題由持續整合來暴露展現出來，提醒我們避免低階錯誤。

二、持續化整合工具——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日誌。

三、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檔案。