2018年度总结-iOS自动化构建系统

iOS的业务逻辑和交互效果越来越复杂,代码量也随之越来越大,伴随着越来越大的代码量而来的还有代码的管理和部署的问题。模组化大行其道,但是构建发布任务也越来越费劲了。在开发环境中模组化会将原本的大型应用分割成很多小模块与组件,再在壳工程中合并构建. iOS 中此类系统化自动构建的系统较少, 大部分企业都采用内部自研.例如滴滴的 OneTool.

懒惰是人类进步的阶梯.

资源

在实现自己理念的系统时, 清点手头的资源也是极为必要的一步, 富有富的玩法,穷有穷的玩法, 合适最重要.

  1. Git云服务器 1 台.
  2. CI云服务器 1 台.
  3. Mac构建服务器 1 台.

工具链

几件趁手的兵器.

  1. fastlane: 用Ruby语言编写的一套自动化工具集和框架.
  2. NodeJS: 一个基于 Chrome V8 引擎 的 JavaScript 运行时.

流程设计

流程设计一般都是由简入繁,慢慢沉淀出适合自己团队的流程.在实现流程时笔者遭遇了一些有趣的问题与心得:

  1. 拥抱git,这是一个耗时极长的过程,尤其是对一个主体业务仍然在 svn 上的公司而言. 市面上主流的工具大多依赖于 git 方式的版本管理.初期笔者在svn上挣扎了许久,但是游说上级实验性使用git的成效更快.
  2. 多端接入(H5 & Android),凡是涉及到多部门或多人合作的事项都是耗时极长,尤其是推动无关业务方面的工作.先行试点,后期推广可能会有效果一些.
  3. 新技术栈的学习,有趣.

本司流程架构图:

  1. 模组化方案设计(还没写完)
  2. fastlane实践(有计划写)

自问自答

为何不采用Jenkins?

ans:

笔者推荐使用更加标准化的 CI 工具: Jenkins !
笔者不采用主要是因为:

  • 笔者只需要构建服务
  • Jenkins中配置构建任务,有点繁琐.(其实就是没配置成功)
  • 学习成本有点高.
为何有2套NodeJS程序?

ans:

云端的NodeJS实际上是一套转发服务,Mac端才是主CI服务.

主要是因为3点问题:

  • iOS依赖Xcode工具链.
  • 国内无主流的Mac云服务器.(国外有Travis CI)
  • 本地Mac构建服务器无公网IP.

后期规划:

  • 若有多台本地Mac构建服务器,则可在远端编排构建任务.
为何没有git提交审核?

ans:

按道理需要这部分服务!

主要是因为2点问题:

  • 人员不多
  • 在本地提交会先经过SwiftLint代码规范审查与 pod lint 编译检查, 这步主要是靠团队文化.

后期规划:

  • 没有, 不必提早优化
test/release环境如何切换?

ans: 我们采用了一个 Env 基础组件库来控制业务模组中的环境判断,在构建前会通过shell修改Env库的配置.

例如微信的服务注册则在一个业务模块中,通过路由激活.

为何采用 fastlane?

ans:

  • 快!
  • 支持iOS && Android
为何未考虑其他端构建? 例如android & h5?

ans: 需要先游说他们迁移到 git 先, 一步一步来.

壳工程中各模组版本如何管理?

ans: 我们处理的方式: 组件锁定版本号, 模块则默认使用最新版本.

编译失败如何处理?

ans: 理论上需要邮件通知触发构建仓库提交者. 笔者没处理该部分(出现几率小,科能是人少的关系).

CI触发时机?

ans: 推荐 webhook 监听 tag 创建事件.

相关链接

2018年度总结-iOS路由(Khala)设计

2018年度总结-iOS模组化

2018年度总结-iOS自动化构建系统