Fastlane实战(二):Action和Plugin机制

作为架构师的我们常常要面临的一个难题就是技术选型。现在无论是商业项目也好,开源项目也好,可供选择的方案实在是太多,其中优秀的方案也是层出不穷,这就要求我们在做技术选型的时候,需要从多个维度进行考量,其中良好的扩展性是我们重点考量的对象。

任何一个优秀的框架或平台都应该具有良好的扩展性,以满足不断变化的业务场景和个性化要求,而这种扩展性的其中一个方面则体现在:是否能够提供一种机制,这种机制既能满足二次开发的便捷性,又最小化甚至不会对原有的系统产生任何的侵入或破坏。

站在这个角度上,今天我们就来介绍一下Fastlane的两种扩展机制,Action和Plugin。

Fastlane的Action机制

Fastlane本身包含两大模块,一个是其内核部分,另外一个就是Action了。Action是Fastlane自动化流程中的最小执行单元,直观上来讲就是Fastfile脚本中的一个个命令,比如:git_pull,deliver,pod_install等等,而这些命令背后都对应一个用Ruby编写的脚本。

我猜想,Fastlane的作者们在项目的早期甚至规划的阶段,应该就考虑到了这一点:在移动开发中,自动化的业务场景太多,每个团队都有自己的特殊要求,单靠一两个人的力量是无法满足的,所以如何将涉及到实际业务的功能开发,用优雅的方式交给开源社区中庞大工程师们来维护,成为Fastlane架构中需要重点考虑的内容。

于是经过不断的探索,讨论和实践,Action这种扩展机制应运而生。我们可以理解为Fastlane建立了一套完整的规则,这个规则是如此的简单易行,无论是官方的工程师还是开源社区的工程师们,大家都在这个规则里进行游戏,这样不但降低了扩展的门槛,吸引工程师们来完善Fastlane本身;同时又增强了约束,减少不必要的沟通和代码检查成本。所以我们可以看到无论是官方贡献的,还是Github社区贡献的Action们,无一例外都隶属于Action扩展的一部分。

到目前为止Fastlane包含大约170多个Action,大约分为如下几类:

  1. 和移动端持续交付相关的15个核心的工具链:如:deliver(上传ipa,截屏和meta信息到ITC),supply(上传apk,截屏和meta信息到Google Play),sigh(iOS Provisioning文件管理)等等,详情如下:https://github.com/fastlane/fastlane#fastlane-toolchain
  2. 和iOS相关的,如:ipa,xcode_install等等
  3. 和Android相关的,如:gradle,adb等等
  4. 和版本控制相关的,如git_pull,hg_push等等
  5. 和iOS依赖库管理相关的,如:cocoapods,carthage等等
  6. 第三方平台对接相关的,如:hipchat,jira,twitter,slack等等

这些Action的详情和使用方法可以查看这个链接:https://docs.fastlane.tools/actions/Actions/

应该说几乎涵盖了所有常见的场景,但是如果仍然无法完全满足你的要求的话,就得自己来动手自定义一个了。

场景分析

1 2 3 4 5 6 
下一页