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

• 原文地址：Five Options for iOS Continuous Delivery without Fastlane
• 原文做者：Shashikant Jagtap
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：金西西
• 校對者：allenlongbaobao，talisk

不使用 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。