我的 iOS 工程化发展史

最近对 CI/CD 有一些实践，记录一下。
每个人对事物的认识都是有一个发展过程的，我也不例外。

手动时代

刚开始 iOS 开发的我，工作流是这样的

1. 开发功能自测功能没问题，提测
2. 接着通过 Xcode 手动出包，完了导出来，上传到平台供测试下载
3. 测试发现 bug，修复 bug，再重复一次步骤 2

这个流程的缺点是耗费人力，以及没有单元测试，无法确保质量。

半自动时代

后来，接触到了 Jenkins 以及一些脚本知识
于是我就写了个发包的脚本，依赖安装、编译、打包、发布一气呵成。配合 Jenkins 只需要点击一下就行了。
我的工作流变成了如下流程：

1. 开发
2. 完成功能自测功能没问题就提测
3. Jenkins 出包
4. 修改 bug，重复步骤 3

这个流程让我尝到了脚本的甜头，省去了跑 Xcode 出包的繁琐过程。但是仍然没有单元测试，无法确保质量。

自动时代

这里要提一件事，有很长一段时间我在用 Go 刷 Leetcode，加上 Go 对测试的原生支持，我养成了写单元测试的习惯。

这段时间换了公司，为了熟悉项目，写起了单元测试。同时配合 fastlane 把单元测试、打包、发布等任务都脚本化了。虽然命令已经简化到极致，然而同事们并没有使用的欲望，于是我开始思考是否有更好的方式。

通过一次公司的分享，了解到了 Gitlab 的 CI/CD，我立马就开始尝试。因为脚本都写好了，集成起来就是写个配置文件，很快就搭建好了，同时也集成了飞书。
现在的工作流如下

1. 开发，push 代码
2. Gitlab 触发 依赖安装、编译、单元测试 流程，将结果通过飞书送达，如失败则重复步骤 1
3. 发布时，push tag
4. Gitlab 触发 依赖安装、编译、单元测试、发布 流程，将结果通过飞书送达，如失败则重复步骤 3 或 1

这样的工作流，可以持续对项目进行验证，在流程上就能提早发现问题；同时发现问题之后，也能根据 push 信息落实到相关开发人员进行修改。
而且更进一步，Gitlab 还支持配置单元测试覆盖率，我们是一个 Framework 服务，接入方看到覆盖率会更加有信心接入。

总结

一个工程会涉及到的任务

• 依赖安装
• 编译
• 单元测试
• 打包
• 发布到测试环境
• 发布到生产环境

什么是 CI/CD，我理解就是根据预先定义的规则以及程序，让以上的任务都自动化的工作流。
目前已经有很多 CI/CD 的方案了，如 Github 的 Actions、Travis CI，Gitlab 的 CI/CD。读者们都可以尝试一下。