Fastlane 是一组工具套件,旨在实现iOS应用发布流程的自动化,并且提供一个运行良好的持续部署流程,只需要运行一个简单的命令就可以触发这个流程。
Fastlane是一个ruby脚本集合,其中囊括了向苹果商店提交新应用或更新已有应用所需要的最常用任务。
这个套件支持与 Jenkins 和 CocoaPods , xctools 等其他第三方工具的集成,并且能够定义多个 通道( lanes ) 以支持不同的部署目标,如应用商店,Beta测试和测试。
fastlane典型的工作流程如下:
lane :appstore do increment_build_number cocoapods xctool snapshot sigh deliver frameit sh "./customScript.sh" slack end
为了了解到更多关于这个项目的信息,InfoQ采访了Fastlane的发明者 Felix Krause 。
持续交付/部署能够给iOS应用部署流程带来的最大收益是什么?在苹果的审核流程框架之下,这个工具能够多大程度地发挥作用?
最主要的收益就是能够在每次发布一个更新或全新应用的时候可以为你节省大量的时间。这是iOS开发者必须亲自完成的工作。
在刚刚启动这个项目的时候,我并不确定是否能够将iOS应用发布流程的各个方面完全自动化,因为并没有公开的API来实现它。令人高兴的是,它的确能够正常运转,而且我已经为多家公司制定了完整的持续部署解决方案。
可否为我们简单描述一下使用fastlane的典型的工作流程?其中最相关的定制化选项有哪些?
我主要在如下场景下使用fastlane:
在http://fastlane.tools网站上可以找到一些简单的例子。每个开发者都可以很方便地添加或删除单个构建步骤,甚至可以实现自己的构建步骤。
你认为什么类型的组织(例如独立开发者,小型开发组织,大型企业等)能够从fastlane的使用中受益最多?
独立开发者和处于初创阶段的小型开发组织:这类组织通常还没有运行任何自动化流程,很容易就可以开始使用fastlane。大型企业通常都已经有了某种类型的持续集成工具,他们需要适应fastlane的使用。
可否告诉我们一些关于fastlane当前采用率的情况?现在有什么成功案例么?
我不想自卖自夸,不过我可以分享一些数字:
我已经从一些知名的公司得到反馈称,他们已经成功地将fastlane工具集成到了他们的发布流程中。 Panic 是我得到反馈最大的公司之一。
驱动你创建fastlane的过程是怎样的呢?
我最初只为一个客户实现了fastlane,当时的fastlane与他们的系统结合十分紧密。当我跟其他的开发者谈论此事时,他们非常兴奋并且询问他们是否也可以使用这个工具。这就是为什么我以一种十分灵活并且文档齐全的方式开发这个工具以便将其共享给其他iOS开发者。
最初我只开发了 deliver 。之后我意识到还缺少一些工具,这就是为什么我又创建了另外四个工具(snapshot,frameit,PEM和sigh)。因为这些程序都是独立运行的,我又想到以某种方式将它们连接起来。也就在这时我有了fastlane的想法。
Fastlane是一个开源的工具集,可以 从Github得到它的克隆 。从 官方指南 中可以了解到关于安装、配置和使用这些工具的更多细节信息。
查看英文原文: Fastlane Brings Continuous Deployment to iOS