前言
做 iOS 项目开发,日常开发中总少不了打测试包以及发布上线等操作,小的团队比较灵活,一般有专人负责上线,Debug 的时候测试同学直接找到开发要测试包。大的团队就要考虑沟通成本问题,产品同学和测试同学想要测试包的时候,都不知道该找谁,而且让开发同学每天频繁的打包上传测试平台也是十分消磨人的耐性,这个时候就需要一个内部的平台,由开发和运维负责维护并提供操作说明,最好由测试同学操作平台,执行打包测试、或者发布上线的操作。
解决这个问题,最常用的办法就是使用 Jenkins 进行持续集成,关于 Jenkins 的配置,这里不做说明,网上已经有很多的教程。使用 Jenkins 进行打包的时候其实还是要调用 Xcode 的命令行工具进行编译打包导出操作,那么这个过程就需要脚本来执行任务。
Shell 脚本
今天我们来说说使用脚本进行自动化打包。说到脚本,最常接触的应该是 shell 命令(文件名后缀为 sh),使用 shell 脚本打包的例子如下(适用于多 xcconfig 配置下自动化打包):
1 | ################## config ################## |
Swift 脚本
其实除了常规的 shell 命令、Python 脚本这些,Swift 也是支持脚本化编程的,而且每台能打包的机器上肯定都安装了 Xcode,天然支持 Swift 的运行环境,Swift 的版本还会跟着 Xcode 的升级自动提升,使用到最新版本的改进。
我这这里抛砖引玉,将我目前在用的脚本分享出来,希望大家能够提出改进意见,或者更加实用的方案。当前在用的方案示例:
1 | #!/usr/bin/env swift |
脚本编写完成后,文件后缀可以是 .sh
,也可以是 .swift
,记得使用 chmod +x
命令给脚本赋予可执行权限。
存在的一些问题
目前使用 Swift 进行脚本编程,还有一些问题。Swift 脚本并没有 sh 脚本与终端结合的那么好,在日志输出方面表现的比较明显, sh 脚本能够做到实时输出,目前 Swift 脚本需要搭配 shell 命令使用,执行 shell 的时候只能等一条命令执行完毕后才能够进行输出,而且输出的内容没有颜色,这是一个弱势,希望后续能够得到改善。