[译] 不使用 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、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。