使用Fastlane从疯狂中拯救您的手机

当您开始编写iOS应用程序时,通常会专注于构建和交付该应用程序。 这意味着要编写代码,也许要进行一些单元测试以确保您的逻辑能够按预期工作,并需要一个或两个脚本来在持续集成系统中构建和运行您的应用程序。

然后,如果碰巧,您的应用程序将受到青睐,您将获得很多客户。 很多很多很多客户。

也许像我们一样,您的客户将需要您的应用以自己的艺术品品牌化。 因此,您编写了一个小的Bash脚本,可以在需要时将其替换为您的图稿。

然后,您的某些客户需要其他客户不想要的特殊一次性功能。 这些客户对您的公司至关重要,因此您可以编写功能并通过特殊的属性文件与另一个启用或禁用该功能的小型Bash脚本组合来对其进行管理。

一段时间后,您的客户群将增长,您的团队将像我们一样增长,并且小型Bash脚本的规模和复杂性将会增长。 很快,其他团队成员将无法理解所有内容如何融合在一起,一个小的更改可能以意想不到的方式破坏其他内容,并且每当需要在构建中进行某些更改时,每个人都会畏缩。

使用Bash构建的复杂构建系统就是这种痛苦。

在Appian,我们的构建系统陷入了这种悲惨的境地。 在几次事件要求我们争先恐慌地修复构建系统更改以重新启用我们无意间破坏的功能之后,我们对系统的信心一直处于低位,压力水平超出了预期。

退后一步,我决定必须做些事情。 我们的构建系统需要修复。 我在团队中提出来,我们考虑使用Python,Swift或Ruby构建我们自己的系统,以便获得高级语言的好处。 我们决定不这样做,因为我们不想重新发明轮子,这将花费很长时间。 那就是我们开始寻找更好的东西的时候。 值得庆幸的是,我的一位同事找到了快车道。

我马上就知道快车道很特别。 它为安装不同版本的Xcode提供了支持; 它承诺会自动上传到TestFlight; 它使自动化测试的输出看起来如此简洁明了。 它是用高级语言Ruby编写的,它使我们能够构建模块化,可理解且可测试的构建系统。

我使用Appian的IndieTime(类似于Google的20%的时间)将整个构建系统转换为使用fastlane,结果是纯粹的欢乐

现在,我们可以依靠为所有不同的构建选项获得正确的结果。 我们的开发人员发现,它更易于理解和更改构建系统,而复杂的项目更改则更容易实现。

使用新系统,我们获得了很多好处。 这三个最突出:

1.使用RSpec的自测试构建系统

当我们在构建系统中使用Bash脚本时,很难确保仍正确构建所有配置。 当我们添加新功能或修改系统时,很容易犯一个错误并引入一个错误,该错误有时几个月都不会出现,直到我们需要向客户提供其自定义版本为止。 当确实出现此类错误时,可能需要很长时间才能确定根本原因,然后正确解决。

有了基于Ruby的fastlane工具集和RSpec,我就能够对整个系统进行单元测试。

现在,每当我们添加涉及对构建系统进行更改的新功能时,我们都会添加单元测试。 我们的持续集成系统运行160多个测试,以确保我们正确构建不同的iOS配置。

2.使用快速通道的简化逻辑

使用Bash,为了不破坏我们现有的构建脚本并节省时间,开发人员将复制Bash脚本并调整副本。 我们的iOS代码库最终以许多几乎相同的脚本以及晦涩,纠结和难以理解的代码为结尾。

过渡到Fastlane时,我们的一位开发人员建议将每个构建都视为自定义构建。 因此,现在,每个构建都遵循相同的自定义路径:

  • 我们的App Store应用,
  • 我们内部的应用程序
  • 我们的HockeyApp
  • 和为我们的客户定制品牌的应用程序。

这样,我们可以确保我们所有的构建工作正常进行,或者我们可以很快发现是否损坏了某些东西。

例如,这对我们有何帮助:Apple刚刚添加了一项新要求,即我们需要将iTunes图稿与应用程序捆绑在一起。 为了进行更改,我们添加了6行以支持所有不同的版本:

我们的产品经理无法相信为我们提供的所有构建配置支持此功能多么容易

3.使用Xcodeproj进行简单但复杂的项目操作

通过对自定义属性(也称为功能切换)进行运行时检查,可以轻松管理客户在应用程序中所需的一些独特功能,而其他功能则需要对项目进行更基本的更改。 有时,这些更改与我们其他客户的需求不兼容。

例如,我们的某些客户要求我们的应用程序与外部设备集成,而其他客户要求我们的应用程序与移动应用程序管理(MAM)SDK集成。

如果保留其中的某些项目更改,将导致我们的应用程序被Apple的App Store拒绝,或者不允许我们使用最新的iOS API的功能。

在我们使用Bash运行sed调用来搜索和替换Xcode项目文件中的文本之前。 这是混乱且容易出错。

现在,在我们的快速fastlane代码中使用xcodeproj Ruby Gem的惊人功能。 它使我们能够动态优雅地编辑Xcode项目文件, 然后构建为:

  • 从“编译构建”阶段删除Swift 3文件。
  • 使用Xcode 7进行构建时,请更改“运行脚本构建阶段”。
  • 从依赖项中删除Notification Extension Targets,然后关闭“推送通知”。

入门建议

如果您对构建一个优雅而强大的构建系统感到兴奋,那么我建议您这样做:

  1. 复习我在以下Github存储库中设置的示例代码,即post-fastfastlane。 它演示了如何使用fastlane来构建一致的构建系统,如何使用xcodeproj轻松编辑Xcode项目文件以启用或禁用推式通知,以及如何使用RSpec来确保每个配置的行为均符合预期。
  2. 阅读一些fastlane文档,并查看可用的fastlane操作和插件,以了解您还可以做些什么。
  3. 扫描Xcodeproj的类参考以了解各部分如何协同工作以及如何编辑自己的项目。
  4. 查看Relish发布的精彩的RSpec文档,以了解如何在构建系统中添加测试。
  5. 认识到您会犯错误并且需要调试代码,因此请获取Ruby Gem pry-byebug 。 它是救命稻草:学习,使用,爱护它。

最后的想法

当您的需求很小时,Bash可以很好地使用,但是一旦您开始添加逻辑或者需要部署到Apple的App Store或TestFlight,您确实应该升级到出色的构建工具,例如fastlane和Ruby Gems,例如xcodeprojblackberry_mam等。 。

从Bash作为构建系统的基础转移到高级构建系统,不仅使您的开发人员更加满意,而且还将使您的产品经理更加满意,最重要的是,它将帮助您使客户满意。

考虑如何改善构建系统:

  • 您有什么浪费的冗余?
  • 您的构建系统在哪里浪费时间和资源?
  • 什么是最大的突破,您或您的开发人员在构建系统中最讨厌做什么?

您有可能使用fastlane解决这些问题。

想象最好的构建系统,然后敢于构建它!