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

6,178 阅读7分钟

前言

之前总结写了关于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的证书仓库目录结构为:

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

  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命令的提示](/Users/gzx/Desktop/屏幕快照 2018-11-28 下午2.42.46.png)

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

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

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

总结

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

参考文档

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