使用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 運用在現有的證書環境下