使用fastlane match自动和手动管理证书

前言

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

上一次了解了match后，发现match有比较多的局限，主要问题在于证书和配置文件必须从新生成，不能使用原有的证书和配置文件，因为公司的证书和配置文件已经生成好了，而且不能随便销毁和删除，因此但愿沿用现有的证书。经过查阅资料，仍是找到了手动上传配置文件和证书的方法。

自动生成证书和配置文件

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

1. 准备一个全新的远端仓库，用来存储生成的证书和配置文件

2. 在开发者网站上建立须要生成证书和配置文件的App ID（这一步不太肯定是否必须作，使用高权限的开发者帐号match可能会自动建立App ID）

3. 在主项目的工程目录下，初始化生成Matchfile文件，固然首先须要安装好fastlane

   fastlane match init
   复制代码

4. 在Matchfile中写入以下配置

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

5. 配置好后，在主项目工程目录下执行：

   fastlane match development --verbose
   复制代码

   运行这个命令过程当中会让输入一个passphrase的密码，记住这个密码，在别的机器上同步证书和配置文件时会用到。运行过程当中还会遇到不少问题，多百度基本能够搞定。

6. 成功生成证书和配置文件以后，使用命令在别的设备上安装证书：

   fastlane match development -- readonly --verbose
   复制代码

7. 若是须要更新证书，使用下面的命令会删除开发者帐号下面的全部development证书，同时删除仓库中的证书，而后就能够从step 2开始从新生成证书和配置文件了。

   fastlane match nuke development --verbose
   复制代码

手动上传证书和配置文件

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

1. 构造证书仓库的目录结构

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

    

2. 找到现有证书的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来寻找的。

3. 加密证书和配置文件

   从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

   注意加密证书和配置文件的密码必须一致，在其余设备同步证书和配置文件的时候须要输入这个密码

4. 将加密好的证书和配置文件放到对应目录中，并提交上传仓库

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

5. 使用命令验证证书有效性

   在对应工程目录执行：

   fastlane match development --verbose
   复制代码

   若是成功，说明建立的证书没问题。

6. 在其余设备使用证书

   在其余设备上使用命令同步证书和配置文件：

   fastlane match development --readonly --verbose
   复制代码

   须要输入上面加密的密码，以后同步成功。

其余的局限性

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

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

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

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

• nuke命令很危险

  一听这个单词就很可怕，用核武器攻击，我原本打算尝试使用nuke命令注销证书和配置文件的，但看到命令提示仍是怂了，==执行nuke命令是会注销帐号下面全部的证书和配置文件==，不是只注销对应bundleId的证书和配置文件，要是本身的开发者帐号还能玩玩，对于公司开发者帐号来讲仍是算了（没有尝试运行这个命令）。 

• 更新证书和配置文件比较麻烦

  我理解nuke命令其实主要是用来更新证书用的，说是更新实际上是重置，命令比较危险。在现有的证书状况和开发人员管理状况下，distribution的证书和配置文件比较稳定，由于你们共用一个证书，配置文件基本也没什么修改的余地，除了有过时风险；而development的证书和配置文件改动就比较多了，一旦添加或注销设备都须要更新证书和配置文件，若是仍是用match命令自动生成，就得先nuke，而后从新建立，或者手动从新上传证书和配置文件。

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

总结

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

参考文档

1. Fastlane证书管理（一）：cert、sigh
2. Fastlane证书管理（二）：match
3. iOS 用fastlane进行团队证书管理
4. fastlane match 运用在现有的证书环境下