• 原文鏈接 : Continuous Integration & Deployment for iOS Projects

• 原文作者 : Matt Oakes

• 譯文出自 : 開發技術前線 www.devtf.cn

• 譯者 : Sam Lau

• 校對者: Mr.Simple

當實現新功能時，如果忽略可維護性而引入技術債務，那將會需要延遲解決它或導致增加維護成本。

最近我們已經思考通過哪些方式來提高代碼的質量：

• 當代碼的質量下降時，通過設置一些工具來馬上提醒開發者

• 文檔化一些編碼規范和思考在過去的幾個項目中如何避免維護性差的問題

我將會簡單地概括我們需要設置什麼才能自動監控代碼質量.

基礎

我們選擇一個持續集成工具Jenkins，讓它運行在一台放在我們工作室的Mac Mini。其實我不怎麼喜歡Jenkins，但到目前為止，它是最穩定和最適合的工具來完成這些工作。

我們已經通過Homebrew和rbenv來分別安裝Jenkins和Ruby，而rbenv能夠為我們提供一個最新和穩定的Ruby Gems環境。有個Homebrew和Ruby Gems兩個包管理工具之後，我們就幾乎能夠安裝所有我們需要的工具，但很少會破壞與原有OS X系統更新提供的Ruby。

單元測試

我們使用Specta和Expecta來測試我們的iOS項目。

Specta讓我們采用行為驅動開發(BDD)風格的語法來編寫測試，相比於XCTest的語法，它更加易讀。它還有一個強大的分組測試功能，在測試之前或之後運行一些代碼塊，這樣的話，能夠極大地減少重復代碼。

Expecta是一個匹配器框架，我們可以在測試中使用它來創建斷言。它的語法非常強大，與此同時，它比內建的XCAssert套件更加易讀。例如：

expect(@"foo").to.equal(@"foo");
expect(foo).notTo.equal(1);
expect([bar isBar]).to.equal(YES);
expect(baz).to.equal(3.14159);

我們在開發時，通過XCode來運行測試；而使用通過Homebrew來安裝的Jenkins時，會借助XCTool。XCTool是一個可代替的選擇來xcodebuild，它能讓你通過命令行的方式來非常輕松地運行測試套件和生成JUnit風格的測試報告。

$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml test

這些測試報告會發布在Jenkins上，而Jenkins會使用JUnit Plugin來根據時間的推移提供單元測試結果的圖表，同時會向我們顯示我們的測試是否穩定。

Pull Request測試

我們想我們的測試盡可能運行以至於如果我們破壞什麼東西，我們就會馬上知道。我們在feature branches做些修改，然後提交一個pull request到Github，那麼代碼就會被另一個開發者審查。只要被打開，我們就能運行所有的測試來確保沒有任何東西被破壞。

當新的pull requst是開放狀態時，為了管理這些，我們安裝Github Pull Request plugin來將信息從Github發送到Jenkins。如果有任何測試失敗，它將會顯示在Github，然後我們就不將代碼合並，直到代碼被修復為止。

代碼覆蓋率

我們也會用Gcovr工具來生成代碼覆蓋率報告，Gcovr的安裝方式也是Homebrew。你需要針對main target的debug congfiguration改變兩個構建設置來配置項目。將Generate Test Coverage Files和Instrument Program Flow都設置為YES。

當我們運行單元測試來生成代碼覆蓋率報告時，我們需要將OBJROOT=./build添加到XCTool命令行的尾部。

$ gcovr -r . — object-directory build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/x86_64 — exclude ‘.*Tests.*’ — xml > coverage.xml

Gcovr輸出的代碼覆蓋率報告也會被插件Cobertura Jenkins plugin發布，這個插件會提供一種可視化的方式來根據時間的推移來顯示代碼覆蓋率。

現在我們不僅可以看到測試是否通過，還可以看到代碼的測試覆蓋范圍。

靜態分析

在工具集中，其中一個強大並能夠保持高質量的代碼的工具就是靜態分析工具。這些工具會掃描你的代碼，然後生成一個報告，這個報告會告訴你破壞代碼風格規則的代碼位置。舉幾個規則的例子：

• 未使用的變量或參數

• 長變量名，方法名或代碼行

• 覆蓋一個方法，但沒有在這個方法調用super

• 方法太長或方法過於復雜

• 還更多的規格…

我們使用OCLint靜態分析工具，這個工具能夠支持C，C++和Objective-C語言。OCLint通過結合XCTool使用來生成json-compilation-database reporter

，從而提供great integration特性。我們首先添加另一個reporter到我們的XCTool命令行，然後將那個report傳遞到OCLint來執行靜態分析。

$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml -reporter json-compilation-database:compile_commands.json test
$ oclint-json-compilation-database -e Pods -report-type pmd -o oclint-pmd.xml

這個report以PMD的方式來生成，然後使用PMD Plugin被發布到Jenkins。有了這些插件之後，你也可以在測試失敗之前，設置每個警告的優先級(底，中，高)中一些限制。最初，我們設置這些限制為低，那麼只要我們引入代碼，就會被提醒，從而提高代碼質量。

自動部署

最後一個問題不是如何提高代碼質量，而是如何節省時間。開發者通常都會將編譯好的代碼通過Crashlytics發送到設計師來設計審查，或在sprint結束演示時發給用戶。發送一個已經編譯好的app通常花一個開發者的10分鐘左右時間，但它需要他們來切換任務和干擾他們的心流。

最近我們已經配置一個在夜晚構建系統，它會在早上自動發送一個新版本的app給每個人。

為了做到這樣，我們使用fastlane。fastlane是一個定義lanes的一些操作來執行的強大工具集。現在我們有三個已經定義好的lanes，一個是用來發布給ribot開發者，一個是用來發布給在ribot的每個人，最後一個是發布給用戶。

before_all do |lane|
 cert
 sigh
end
desc “Deploy a new build to ribot iOS developers over crashlytics”
lane :dev do
 ipa
 crashlytics({ groups: ‘ribot-developers’ })
end
desc “Deploy a new build to people at ribot over crashlytics”
lane :internal do
 ensure_git_status_clean
 append_build_time
 ipa
 crashlytics({ groups: ‘ribot’ })
 reset_git_repo
end
desc “Deploy a new build to everyone over crashlytics”
lane :external do
 ensure_git_status_clean
 increment_build_number
 ipa
 crashlytics({ groups: [‘ribot’, ‘client’] })
 commit_version_bump
 add_git_tag
 push_to_git_remote
end
after_all do |lane|
 clean_build_artifacts
end

通過使用fastlane工具(通過Ruby Gems來安裝)來運行一個lane。

fastlane internal

在開始使用所有的lanes之前，我們應該自動確保我們有一個有效的signing certificate和最新的provisioning profile。所有我們的配置都放在一個.env文件，它讓我們有些默認配置，但當我們運行fastlane根據需要來覆蓋它們。

在將來，我們會通過使用deliver操作來自動化app store提交過程。

最後總結

到目前為止，我們已經嘗試這些過程，並在工程中呈現出好的結果。我們期望看到只要適當地使用這些工具，就能提高代碼的質量，這些報告將會讓我們隨著時間推移來量化代碼質量。我們期待在下一個工程中適當地使用這些工具會發生什麼。