前言

之前总结写了关于fastlane match命令，当时只是说了一下match是什么，match的一些常用命令等。本次是写进一步了解match命令之后的总结。

上一次了解了match后，发现match有比较多的局限，主要问题在于证书和配置文件必须重新生成，不能使用原有的证书和配置文件，由于公司的证书和配置文件已经生成好了，并且不能随便销毁和删除，所以希望沿用现有的证书。通过查阅资料，还是找到了手动上传配置文件和证书的方法。

自动生成证书和配置文件

先来回顾下自动生成的方案：

准备一个全新的远端仓库，用来存储生成的证书和配置文件
在开发者网站上创建需要生成证书和配置文件的App ID（这一步不太确定是否必须做，使用高权限的开发者账号match可能会自动创建App ID）
在主项目的工程目录下，初始化生成Matchfile文件，当然首先需要安装好fastlane
```
fastlane match init
```

在Matchfile中写入如下配置

git_url("https://gitee.com/xxxx/xxxxxxx.git") //新建一个项目,将地址复制到这里
type("development") # 默认match所同步的类型,可不管
app_identifier("bundle Id")  #bundleId,若同工程下有多个,则用["bundleId1","bundleId2"]
username("user@fastlane.tools")  #苹果开发者账号

配置好后，在主项目工程目录下执行：
```
fastlane match development --verbose
```
运行这个命令过程中会让输入一个passphrase的密码，记住这个密码，在别的机器上同步证书和配置文件时会用到。运行过程中还会遇到很多问题，多百度基本可以搞定。
成功生成证书和配置文件之后，使用命令在别的设备上安装证书：
```
fastlane match development -- readonly --verbose
```
如果需要更新证书，使用下面的命令会删除开发者账号下面的所有development证书，同时删除仓库中的证书，然后就可以从step 2开始重新生成证书和配置文件了。
```
fastlane match nuke development --verbose
```

手动上传证书和配置文件

查阅了参考文档[1][2]后，发现match命令是结合了cert命令和sigh命令生成证书和配置文件的，生成过程中会判断仓库中是否有合适的证书和配置文件，我们就可以通过这个机制来手动构造类似match仓库的文件结构，并且手动生成好合适的证书和配合文件，放到相应的目录中，再推到仓库中。

构造证书仓库的目录结构

match的证书仓库目录结构为：

![证书目录结构](/Users/gzx/Desktop/屏幕快照 2018-11-28 下午4.10.24.png) ![配置文件目录结构](/Users/gzx/Desktop/屏幕快照 2018-11-28 下午4.10.38.png)

找到现有证书的cert id

使用ruby脚本读取开发者账号中的所有证书，找到对应证书的Cert id，ruby脚本为：

require 'spaceship'

Spaceship.login('xxxxxx@xxx.com') #输入对应的苹果账号
Spaceship.select_team

Spaceship.certificate.all.each do |cert| 
  cert_type = Spaceship::Portal::Certificate::CERTIFICATE_TYPE_IDS[cert.type_display_id].to_s.split("::")[-1]
  puts "Cert id: #{cert.id}, name: #{cert.name}, expires: #{cert.expires.strftime("%Y-%m-%d")}, type: #{cert_type}"
end

其中打印出来的cert对象是证书对象，一个inHouse类型的证书对象其结构为：

<Spaceship::Portal::Certificate::InHouse 
id="GF0ZY66W6D", 
name="iOS Distribution", 
status="Issued", 
created=2017-12-19 02:52:11 UTC, 
expires=2020-12-18 02:42:11 UTC, 
owner_type="team", 
owner_name="Communications Corporation Limited", 
owner_id="12GF5VQGBX", 
type_display_id="9RQEK7MSXA", 
can_download=true>

这里寻找哪个证书还是挺麻烦的，开发者账号中的证书太多了，我也没有仔细想方法，就是按照日期和owner_id来寻找的。

加密证书和配置文件

从Apple Developer中下载现有的证书及mobileprovision文件，将证书导入到钥匙中，并生成p12文件。得到的证书和配置文件还不能被match识别，需要通过加密命令加密后才符合match的验证要求，其中使用到的命令有：
- 加密证书
  - 执行 openssl pkcs12 -nocerts -nodes -out key.pem -in {证书}.p12 生成.pem文件
  - 执行 openssl aes-256-cbc -k {密码} -in key.pem -out {cert_id}.p12 -a 生成加密后的p12
  - 执行 openssl aes-256-cbc -k {密码} -in {证书}.cer -out {cert_id}.cer -a 生成加密的证书，其中cert_id为前面执行ruby脚本所找到的证书id
- 加密配置文件
  - 配置文件起名需要符合规则 {Development/ADHoc/AppStore/InHouse}_bundleId.mobileprovision
  - 加密命令 openssl aes-256-cbc -k {密码} -in xxxx.mobileprovision -out Development_yyyy.mobileprovision -a
注意加密证书和配置文件的密码必须一致，在其他设备同步证书和配置文件的时候需要输入这个密码
将加密好的证书和配置文件放到对应目录中，并提交上传仓库

以上加密过的cer文件和p12文件放到对应的certs目录下对应的文件夹中，加密的mobileprovision文件放到profiles目录下对应的文件夹中，提交commit到远端证书仓库
使用命令验证证书有效性

在对应工程目录执行：
```
fastlane match development --verbose
```
如果成功，说明创建的证书没问题。
在其他设备使用证书

在其他设备上使用命令同步证书和配置文件：
```
fastlane match development --readonly --verbose
```
需要输入上面加密的密码，之后同步成功。

其他的局限性

解决了match手动同步证书问题，但也意识到match的其他局限性：

使用match手动同步证书有什么意义？

手动同步操作比较麻烦，这样做的好处其实和自己管理证书仓库的区别不大，管理证书人员的工作量基本上没有减少，主要好处在于其他人使用的时候更加方便，不用克隆仓库也不用手动安装证书和配置文件，使用一个命令就可以实现自动安装证书的目的。

个人认为match的初衷还是推荐使用match自动创建证书的，但确实不太明白nuke命令的设计初衷，并且证书更新也是很大的问题，后面会讲到更新证书的问题。可能match更加适合证书变动不太频繁的情况使用。
nuke命令很危险

一听这个单词就很可怕，用核武器攻击，我本来打算尝试使用nuke命令注销证书和配置文件的，但看到命令提示还是怂了，==执行nuke命令是会注销账号下面所有的证书和配置文件==，不是只注销对应bundleId的证书和配置文件，要是自己的开发者账号还能玩玩，对于公司开发者账号来说还是算了（没有尝试运行这个命令）。 ![nuke命令的提示](/Users/gzx/Desktop/屏幕快照 2018-11-28 下午2.42.46.png)
更新证书和配置文件比较麻烦

我理解nuke命令其实主要是用来更新证书用的，说是更新其实是重置，命令比较危险。在现有的证书情况和开发人员管理情况下，distribution的证书和配置文件比较稳定，因为大家共用一个证书，配置文件基本也没什么修改的余地，除了有过期风险；而development的证书和配置文件改动就比较多了，一旦添加或注销设备都需要更新证书和配置文件，如果还是用match命令自动生成，就得先nuke，然后重新创建，或者手动重新上传证书和配置文件。

能想到的比较好的方案就是，不使用邀请开发者的模式，development和distribution的证书和配置文件都由一个账号统一生成并且分配使用，添加设备也由账号管理者统一添加，更改之后可以根据变动大小决定使用nuke还是手动更新证书和配置文件，这个方案主要针对development情况，当然distribution的证书和配置文件也可以使用这个方案更新。

总结

个人认为match也不是特别完美的管理证书的解决方案，还需要根据实际情况分析是否适合使用，如何使用。另外，文章中有什么不对的地方还请读者指出，大家共同进步，谢谢！

参考文档