使用fastlane match自動和手動管理證書

BAOU1371發表於2019-03-04
AST

前言

之前總結寫了關於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 運用在現有的證書環境下

相關文章