[譯] 不使用 fastlane 實現持續交付的 5 種選項

金西西發表於2018-04-12
AST

不使用 fastlane 實現持續交付的 5 種選項

[譯] 不使用 fastlane 實現持續交付的 5 種選項

原文釋出在 XCBlog 這裡

fastlane 工具將整個 iOS CI/CD 流水線（Continuous Integration and Deployment，持續整合和釋出，譯者注）自動化了，使得我們可以用程式碼的方式管理整個 iOS 基礎架構。fastlane 是一系列工具，用來將例如分析、構建、測試、程式碼簽名和 iOS app 打包等一切過程自動化。然而如果你深入看，它不過是在蘋果原生開發工具上加了一個 Ruby 層。可能在某些情況下，fastlane 節省了一些時間，但考慮到頻繁的不相容更改，fastlane 反過來浪費了大量開發者的時間。在不斷學習 Ruby 和 fastlane 式的自動化的過程中，許多開發人員浪費了寶貴時間。就像 CocoaPods， fastlane 可能是你的 iOS 專案中使用到 Ruby 的另一個無用之物，它與 iOS 開發毫無關係。學習一些本地的蘋果開發工具並從你的 iOS 開發工具箱中徹底刪除 Ruby 和其他第三方工具（比如 fastlane）並不難。在這篇文章中，我們將介紹 iOS 開發人員使用 fastlane 面臨的問題以及替代方案。

fastlane 的 5 個問題

fastlane 聲稱它通過自動執行常見任務節省了開發人員的時間。在 fastlane 按預期工作的情況下，這可能是正確的，但也需要考慮到 fastlane 在安裝、除錯和管理方面浪費了多少時間。本節我們將討論 iOS 開發人員使用 fastlane 可能面臨的常見問題。

1. Ruby

在 iOS 專案中使用 fastlane 的首要問題是 Ruby。一般來說，iOS 開發人員並不擅長使用 Ruby，但為了使用 fastlane 或 CocoaPods 等工具，他們必須學習 Ruby，然而這與實際的 iOS 開發沒有任何關係。設定 fastlane 工具需要很好的理解 Ruby、RubyGems 和 Bundler 的工作原理。最近出的 Swift 版的 fastlane 聲稱可以擺脫 Ruby，但實際上只是用 Swift 來執行的後臺的 Ruby 命令。我對 Swift 版 fastlane 的可用性表示懷疑，這篇部落格裡面寫了我對 Swift 版 fastlane 最初的印象。fastlane 有很全的文件，但 iOS 開發人員仍然需要使用 Ruby 來編寫所有用於自動化 iOS 釋出流水線的基礎架構。

2. 頻繁的不相容的更新

蘋果不斷地改變著本地工具，這些改變不斷地導致 fastlane 無法相容。他們需要經常追逐著蘋果和谷歌（以 Android 為例）適配 fastlane，這要求 fastlane 的開發人員實現這些特性併發布新版本。如果 fastlane 版本不是由 Bundler 管理的，那麼大多數情況更新 fastlane 版本的時候也需要更新現有的 fastlane 指令碼。對於可能頻繁出現的構建失敗，iOS 開發人員需要花時間分析 fastlane 中發生的變化並相應地修復。這種破壞性的更新會干擾 iOS 開發人員的主要開發流程，並且要浪費幾個小時來修復構建。使用 fastlane 的一個痛苦點是，在 fastlane 之前的版本中配置的選項並不總是適用於較新的版本，如果你搜尋解決方案，那麼對於同一個問題，你最終會找到對應 fastlane 不同版本的多個解決方案。

3. 耗時的設定和維護

雖然 fastlane 提供了很好的入門指南搭配了模版程式碼，但用指令碼來描述所有的 iOS 自動化釋出流水線需求並不是十分簡單直白的事情。我們需要根據我們的需求定製選項，這需要知道這些選項如何在 fastlane 指令碼中編寫，然後我們才可以使用不同的 lane 來編寫我們的流水線。學習 fastlane 和 Ruby 工具箱需要大量的時間來以完成所有的設定。然而當你設定好所有的東西時，這個工作並沒有完成，你還需要在前文提到的每個 fastlane 的更新中持續不斷的維護。

4. 在 github 貢獻程式碼很難

你可能需要根據公司特定的要求配置 iOS 釋出流水線，或者要求 fastlane 進行定製。唯一的選擇就是為 fastlane 寫外掛。目前編寫外掛的唯一方法是編寫一個 Rubygem，它可以安裝為 fastlane 外掛。同樣，它需要對 Ruby 生態系統有深刻的理解，而通常 iOS 開發人員並沒有相關的技巧。很不幸的是，iOS 開發人員不能為他們目前在工具箱中使用的工具貢獻程式碼。除此之外，給 fastlane 貢獻程式碼的過程耗時且充滿了機器人。它以建立一個 Github 的 issue 開始，進而是無休止的討論。這裡你可以閱讀更多關於 fastlane 的貢獻指南。

5. Github 上未解決的 issue

fastlane 的 Github 上面有很多 issue 是 open 的狀態，有些在還沒有為使用者提供正確的解決方案的情況下就被自動機器人關閉了。我舉個很好的例子，我浪費了好幾天的時間為了確定 fastlane 的 match 是否支援在 Xcode 9 上構建的企業應用釋出包。在尋找答案的同時，我發現還有其他人也在尋找相同問題的解決方案。這是一個沒有得出合適的解決方案的卻被 fastlane 機器人關閉的 issue。我已經嘗試了 issue 11090，10543，10325，10458 等提供的各種解決方案，讀完所有這些之後，我仍然不明白企業應用構建的 export 方法是什麼。有些使用者說：當你使用 adhoc 它會起作用；而另一些使用者則說 Ad-hoc 或者 AdHoc。你可以想象需要花多少時間來給應用打包，去測試每個出口方法。我看到 CircleCI 也有使用者對 fastlane 的 match 的程式碼簽名問題感到沮喪。

上面列舉的是 fastlane 在你的 iOS 專案中製造的所有問題中的一小部分，你可能有不同的故事和不同的問題，但你從來沒有提起。

5 個 fastlane 的代替品

既然我們已經看到了在 iOS 專案中使用 fastlane 的一些問題。現在的問題是我們能否完全移除 iOS 專案中的 fastlane。答案是肯定的。但是，你需要花費一些時間來理解 iOS 構建過程和幾個蘋果原生命令列開發工具。我認為，花時間去了解原生蘋果開發工具，比學習第三方框架更加值得。你永遠不會後悔學習了蘋果原生命令列開發工具，然而如果你沒有時間去學習這些，還有一些免費或者付費服務可以幫你解決所有的問題。目前，我們有以下代替 fastlane 的免費或付費的選擇。

fastlane 的替代者 Top 5

  • 原生蘋果開發工具（免費）
  • Xcode Server（免費）
  • 雲端 CI 服務（付費）
  • Apple + BuddyBuild（天知道）
  • 基於 Swift 的替代方案（免費但尚未準備好）

1. 原生蘋果開發工具

沒有什麼比學習蘋果原生開發工具和編寫自定義指令碼更適合你的構建和釋出過程的需求了。蘋果提供了命令列開發工具來完成我們想要的一切。要知道 fastlane 和類似的工具也是基於蘋果原生開發工具實現的。使用蘋果開發工具的最大好處是，除了蘋果之外，任何人都不能打破它，而且在大多數情況下它們都是向下相容的。蘋果已經給這些工具編寫了文件，而且大多數都有指導手冊來方便檢視這些工具提供的所有選項。為了編寫 iOS 構建流水線，我們需要了解以下主要工具。

  • xcodebuild  —— 分析、構建、測試和打包 iOS app。這是所有命令之父，所以學習這個工具很重要。
  • altool: 上傳 ipa 檔案到 iTunes Connect。
  • agvtool: 管理版本和構建版本號。
  • codesign: 管理 iOS app 的程式碼簽名。
  • security: 管理證書, 鑰匙串和 Profiles。

有一些輔助工具像 simctl，PlistBuddy，xcode-select 等，在處理模擬器、Plist 檔案和 Xcode 版本等有時也會需要。一旦熟悉了這些工具，你就會對自己編寫 iOS 釋出流水線有信心，並且這些工具能夠解決任何問題。在大多數情況下，幾行程式碼就可以將你的 iOS 應用傳送到 iTunes Connect。我寫了一篇文章關於通過命令列釋出 iOS 應用。我們也需要知道一些 程式碼簽名 以理解整個流程。學習在iOS構建過程中應用蘋果開發者工具需要一些時間，但這是一次性的，你不需要學習任何第三方框架，比如 fastlane。

2. Xcode Server

Xcode Server 是蘋果提供的持續整合服務。隨著 Xcode 9 的釋出，蘋果給 Xcode Server 增加了許多新功能，幾乎所有的功能都是在後臺執行。Xcode Server 與 Xcode 緊密結合，對 iOS 開發人員來說很容易上手。使用 Xcode Server，我們可以分析、測試、構建和歸檔一個 iOS 應用程式，並且無需編寫任何程式碼或指令碼。如果你使用 Xcode Server 進行 iOS 持續整合，你可能不需要任何工具來自動化構建過程。這裡可以讀到更多關於 Xcode Server 特性的資訊。然而，還有一個步驟需要我們手動實現：將二進位制檔案上傳到 iTunes Connect 或其他平臺上。目前 Xcode Server 無法將二進位制檔案上傳到 iTunes Connect，但使用 altool 作為 Xcode Server bot 的 post-integration 指令碼就很容易實現這個目標。

如果你無法在內部管理 Mac Mini 伺服器，你可以通過Mac Stadium這類的服務中租用一些 mac Mini 來執行 Xcode Server。

3. 基於雲的 CI 服務

有許多基於雲端計算的 CI 服務，例如 BuddyBuild，Bitrise，CircleCI，Nevercode等，可以提供持續整合以及持續釋出服務。 BuddyBuild 最近被蘋果公司收購，我下一節會介紹。這些基於雲的 CI 服務會處理所有 iOS 構建過程，包括測試，程式碼簽名和將應用程式釋出到特定服務或 iTunes Connect 上。我們也可以編寫自定義指令碼來實現特定需求。這些服務完全避免了對 fastlane 或任何 iOS 專案的指令碼編寫的需求。但是這些服務不是免費的，並且可以控制你的專案。如果你完全不具備 CI / CD 基礎設施的技能，那麼這將是一個不錯的選擇。我在我的個人專案上完成了所有基於這些雲端計算的 CI 服務的關鍵步驟，並寫了我的結論。希望文中的對比和討論能在你為自己的 iOS 專案選擇合適服務的過程上有所幫助。

4. Apple + BuddyBuild

今年年初蘋果收購了 BuddyBuild，這意味著蘋果和 BuddyBuild 可能會合作，為 iOS 開發人員提供無痛苦的持續整合和交付服務。在 WWDC 2018 上如果看到了蘋果和 BuddyBuild 的合作演示估計會很有趣。 我們可以猜測蘋果會將 Xcode Server 作為自己託管的解決方案（免費）並且將 BuddyBuild 基於雲，整合進 Xcode 的解決方案（付費或免費）；或者是蘋果徹底拋棄 Xcode Server，只保留 BuddyBuild 為免費或付費的服務。以上種種可能除非必要，都不需要明顯的指令碼基礎架構。這也將徹底消除對類似 fastlane 這樣的工具的需求。我們目前唯一需要做的就是等到 2018 年 WWDC。

5. Swift 選項（未準備好）

fastlane 最近新增了使用 Swift 而不是 Ruby 來配置通道的支援。但目前這並不是真正的 Swift 實現，因為在底層還是用 Swift 來執行 Ruby 命令而已。它在專案中新增了許多不相關的 Swift 檔案，這些檔案理想情況下應該作為可通過 CocoaPods，Carthage 或 Swift Package Manager 分發的 Swift 包（SDK）提供。我寫了我對Fastlane Swift 第一印象。另一個解決方案是 Autobahn，它是純 Swift 實現的 fastlane，但是它還處在開發階段，在開發完成之前無法使用。遺憾的是，我們不得不等待這些基於 Swift 的解決方案，他們還沒有準備好在當前的 iOS 專案中使用。但是，我們期待遲早會有可行的解決方案，這將允許 iOS 開發人員使用 Swift 編寫配置程式碼。在我看來 Swift 不是指令碼語言，但可以在需要時用作指令碼。

選擇的小建議

現在，我們已經看到了所有的不使用 fastlane 工具實現持續釋出的選擇了。 接下來需要決定選哪個方式，這取決於團隊中工程師的技能和經驗。

  • 如果團隊完全沒有對 CI / CD 知識有了解的 iOS 工程師，那麼可以選擇使用基於雲端計算的 CI 解決方案來處理所有問題。
  • 如果團隊中有少數具有 CI / CD 經驗的 iOS 工程師，那麼可以嘗試使用 Xcode Server，因為配置和使用相當簡單。
  • 如果團隊的 iOS 開發人員有經驗，對原生工具很熟悉，那麼很值得去使用指令碼構建流水線。
  • 等待 2018 年 WWDC 是一個好主意，看看蘋果和 BuddyBuild 將在舞臺上呈現什麼結果。

結論

通過使用蘋果原生開發者工具，我們可以為 iOS 專案編寫整個 CI / CD 流水線，避免了 iOS 專案中需要第三方工具（如 fastlane）的需求。但是需要時間和努力來學習蘋果原生開發者工具。 其他選項例如 Xcode Server 或基於雲的 CI 解決方案可以避免了使用指令碼。

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章