苹果账号证书体系自动化策略

处理苹果相关流程半年多了，每天都在近十个账号之间来回切换，每天都有各种安装证书、添加设备的问题。鉴于此，整理了一个将这个流程自动化的方案。

环境信息

fastlane 2.85.0

padrino 0.14.3(02feacb)

先来说一下背景，现有公司账号七个，企业账号两个，即将新增个人账号八个，测试机 200+，iOS 开发 100+，项目 20+。

再来说一下目标，保证以下的操作流程，都能自动化处理，或者，都能一键处理：

账号相关（Developer / AppStore Connect）

• App 账号迁移
• TestFlight Build 上传与移除
• 人员角色添加与删除（开发者与市场人员，并清理离职人员）
• 账号续费、新协议、设备清理监控

证书相关（cer / profile / 设备）

• AppID 创建，相关根证书、推送证书创建，profile 创建
• 证书、profile、推送证书过期监控与新建
• 设备添加与 profile 更新

设备相关

• 拿到任何一台设备，能知道已经添加到了哪些账号中，能一键下载对应 profile 进行调试
• 对于需要添加的设备，能一键发起请求，进行添加

现有的条件

现有的，能够提供支持的服务有：

• 持续集成服务：已完成 TestFlight 上传功能
• OA：公司 OA 服务
• fastlane match：全部的账号和证书已经统一管理
• fastlane spaceship：提供访问 Developer 和 AppStore Connect 的接口（详情可以看之前的文章 fastlane spaceship 源码浅析 ）

用户管理

对接 OA，fastlane spaceship 能通过登录各个账号，遍历全部 User，然后访问 OA 进行查询用户是否已经离职。

时间节点监控

账号、协议、设备清理这部分都没找到可以直接用的接口，可以自己写脚本爬取。而且这三个需求比较集中，都是在 developer.apple.com 的页面。可以开启定时任务进行监控。

TestFlight

fastlane pilot 已经提供上传 TestFlight 的功能。在 App 进行迁移时，需要将全部 TestFlight 的 Build 设置为过期，这个接口 spaceship 也有提供，可以调用 Spaceship::TestFlight::Build 的 expire! 方法。

证书相关

热身结束，正片开始！关于现有的 fastlane match 的流程，可以参考之前的文章 fastlane match 源码浅析与最佳实践 。

告别 fastlane

由于 fastlane match 会将加密以后的证书和 profile 推的 git 上，所以大家都可以访问，看起来没什么毛病。但是当开发和账号多了以后，会有什么问题呢？

• 请问，我是美拍的开发，我应该拉取哪个分支的证书呢？
• 请问，为什么我的 fastlane 卡在了 clone repo 这一步？
• 请问 xx 账号还能添加设备吗？
• 请问，方便给我开一下 repo 的权限吗？
• 为什么我拉取 xx profile 失败了啊？

每一个问题，都可能有着不一样的原因：

• ssh 未配置。
• 在 git clone 的过程中有输入操作，比如：ssh 设置了密码，know_hosts 冲突等。
• 账号过多，开发并不能理解每一个账号的作用，也并不知道自己项目上架的那个账号叫什么。
• 除了 iOS 开发以外，可能还会有实验室与测试人员需要进行调试。
• 因为账号不开放，导致开发无法知道账号的基本信息。
• 对证书和 profile 不熟悉，导致全部问题都需要进行询问，如当前 AppID 支持的服务等。

其中，最大的问题在于，每个人本地环境千奇百怪，导致出现各种失败。所以，需要解决的首要问题，就是脱离本地环境，本地不再依赖 fastlane。

推送证书

因为 fastlane match 只维护了根证书和 profile，每次推送证书过期、App 迁移、新的 App 注册、开发下载进行调试，都需要手动导出推送证书。而 fastlane pem 这个针对推送证书的 action，每次都只能生成新的，而不能直接下载已存在的。看了一下 issue ，原因是因为没办法知道根证书。

Emmm…这就很微妙了，明明我所有的证书都是你在管理啊 :confused:。更可气的是，那好歹给我提供 cer 的下载，我自己合成根证书可以吧？不可以 。然后打开 pem 源码一看，证书都已经下载了，但就是不给你：

def certificate
  if PEM.config[:development]
    Spaceship.certificate.development_push
  else
    Spaceship.certificate.production_push
  end
end

所以，可以手动调用 spaceship 进行下载，然后手动合成。推送证书，DONE！

整个流程

为了用户本地不再依赖 fastlane，我们做了一个客户端 dogeX。

为了对账号进行分类，方便项目组理解，我们给 dogeX 提供了服务端 dogeX Server。

除此之外，Sever 还会处理证书相关的各个自动化流程，后续还有可能给持续集成的打包服务器提供证书管理服务。

那么，如何将流程串起来呢？

大致就是这个样子的。关于 dogeX Server 的内部设计，都是功能开发了，不再细说。

dogeX Server

都说了不细说，这个 Section 又是什么呢…来谈谈技术选型。

考虑到需要原生支持 fastlane，也就是 Ruby 的调用，所以选择了轻量级 Ruby web framework ———— padrino 。

考虑到 Server 需要调用钥匙串相关命令进行证书、profile 等信息读取，调用 fastlane，所以选择 macOS 做服务器。

最后

整个策略重中之重就在于证书这部分的处理，除了流程上的一些方案以外，账号的定义也是必不可少的。公司账号只添加常用的测试机，保证能够正常调试推送等功能。项目组自己的设备，包括开发人员、测试、实验室、公共支撑等，均添加到每个 BU 自己申请的个人账号中。众多账号之间共用一个 git repo，以分支的形式进行管理。

目前策略大致就是这样，欢迎讨论。