前言

目前比較流行的元件化開發，針對多個 app 要用同一套程式碼，將其做成 pod 倉庫是比較好的解決方案。程式碼只有一份放在元件倉庫，需要整合的 app 只需要將其 pod 到工程內部即可。

如果很多元件都需要做成 pod 庫，每一步都手動去做，顯得繁瑣而且容易出錯。本文主要講一下，怎麼自動化去實現這些事情。不過，在此之前，先概述一下，釋出框架具體需要做哪些事情。如果對發 pod 的流程比較熟悉，直接跳過看自動化實現部分。

先上 GitHub 倉庫地址：

釋出框架到官方庫

注：圖中標號並非和釋出流程標號對應，圖中表述的是從框架釋出到使用的大致流程。

想要釋出框架到 CocoaPods 官方庫，需要有以下流程：

1. 安裝 CocoaPods]
2. 註冊 CocoaPods 賬號]
3. 建立 spec 檔案]
4. 提交程式碼併為框架打 tag
5. 驗證 spec 檔案
6. 通過 pod trunk push 推送 spec 檔案

安裝 CocoaPods

網上有很多教程，這裡不再贅述。需要注意的是，RubyGems 的 淘寶映象 已經不再維護，已遷移至 Ruby China，安裝 CocoaPods 前記得替換 gem sources。

註冊 CocoaPods 賬號

首先需要註冊一個 CocoaPods 賬號，用於釋出 pod 倉庫。

$ pod trunk register EMAIL [NAME]

trunk 命令用於建立一個賬號或是一個 seession。

• 如果你還沒有賬號，則需要將郵箱和名字一起填入，建立賬號的同時會自動建立 session
• 如果已經有了賬號，但是沒有在當前這臺電腦上釋出過 pod 倉庫，這個時候就需要建立一個 session，僅需要填郵箱即可，除非你想改名字，否則不用填寫名字。

你可以對你的 session 進行描述，這樣在利用 pod trunk me 命令檢視所有 session 資訊的時候，可以很清晰地看到在哪些電腦上建立過 session。

$ pod trunk register [email protected] 'Orta Therox' --description='macbook air'

命令成功之後，你的郵箱應該會收到一份郵件。檢視郵件資訊，訪問對應網址即可驗證你的賬號。當然，這個事情做一次就好了，以後基本上不用再操作。

建立 spec 檔案

spec 檔案即一個 pod 倉庫的描述資訊。所有通過 pod search 搜尋出來的框架，都是根據這個檔案中的描述資訊進行匹配的。以下為部分描述資訊：

• 倉庫名字
• 作者
• 證書
• 版本
• 描述
• 程式碼源路徑
• 使用哪些檔案
• 依賴哪些其他框架
• ...

一個簡單的 spec 檔案如下：

Pod::Spec.new do |s|
  s.name             = 'ZYTemplateName'
  s.version          = '0.1.0'
  s.summary          = 'A short description of ZYTemplateName.'
  s.homepage         = 'https://github.com/ripperhe/ZYTemplateName'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { 'ripperhe' => '[email protected]' }
  s.source           = { :git => 'https://github.com/ripperhe/ZYTemplateName.git', :tag => s.version.to_s }
  s.ios.deployment_target = '8.0'
  s.source_files = 'ZYTemplateName/Classes/**/*'
end

先進入需要釋出的框架的根目錄，執行

$ pod spec create [NAME]

這裡的 NAME 即為框架名字，不需要手動加 .podspec 字尾。執行完成之後，會生成 ZYTemplateName.podspec 檔案（這裡以 ZYTemplateName 為例），進入該檔案，將對應資訊改為你具體的資訊即可。

如果你發現你的 spec 檔案預設填寫的使用者名稱和郵箱不是你剛才利用 trunk 命令註冊賬號時候填寫的不用驚訝，因為預設取的是 git 的使用者名稱和郵箱，所以想修改的話，去修改 ~/.gitconfig 檔案中的使用者名稱和郵箱。以下為相關原始碼：

def default_data_for_template(name)
    data = {}
    data[:name]          = name
    data[:version]       = '0.0.1'
    data[:summary]       = "A short description of #{name}."
    data[:homepage]      = "http://EXAMPLE/#{name}"
    data[:author_name]   = `git config --get user.name`.strip
    data[:author_email]  = `git config --get user.email`.strip
    data[:source_url]    = "http://EXAMPLE/#{name}.git"
    data[:ref_type]      = ':tag'
    data[:ref]           = '#{s.version}'
    data
end

spec 檔案的這些描述，基本上看命名是可以看明白的。實在不明白可以檢視 官方文件。需要注意的是，s.version 是你將要釋出的 pod 倉庫的版本，s.source 是你的倉庫源地址和對應的 tag 資訊。

version 和 tag 可以是不同的，但是為了方便管理和維護，我們一般將其設定為一樣的，所以 tag 可以 直接使用 s.version.to_s。既然這裡用到了 tag，那麼接下來，就需要為倉庫程式碼打上 tag。

提交程式碼併為框架打 tag

首先，需要將本倉庫的所有修改提交到遠端倉庫。

$ git add .
$ git ci -m 'release pod'
$ git push

上一步在倉庫的根目錄建立了 spec 檔案，隨著程式碼的提交，spec 檔案也會提交到自己的遠端程式碼倉庫。這個 spec 檔案和需要釋出的框架放在一起並不是必須，只是這樣可以方便我們以後維護這個框架。

釋出 pod 倉庫，需要和自己框架的遠端倉庫程式碼版本對應，所以這裡需要為當前程式碼打上 tag，這個 tag 是和前面的 spec 檔案中填寫的 tag 對應的。框架釋出成功之後，CocoaPods 會根據 tag 資訊去獲取相應程式碼。

$ git push origin master
$ git tag '0.1.0' 
$ git push --tags

驗證 spec 檔案

用於驗證 spec 檔案是否正確，可以及早發現問題。同樣，也是在需要釋出的框架的根目錄，執行

$ pod spec lint ZYTemplateName.podspec

這裡需要加上 .podspec 字尾來驗證這個檔案。如果有報錯，仔細檢視報錯資訊，一般可以定位問題，可以加上 --verbose 檢視詳細的驗證過程，方便定位問題。

$ pod spec lint ZYTemplateName.podspec --verbose

驗證 spec 檔案也可以用另外一個命令

$ pod lib lint ZYTemplateName.podspec

pod spec lint 和 pod lib lint 最主要的區別是，前者會根據 spec 檔案 tag 資訊去驗證遠端倉庫程式碼是否存在，後者不會。簡單理解就是，pod spec lint 聯網檢查，pod lib lint 不聯網檢查。

驗證的時候，可能會報錯，或是報警告。報錯的話，必須解決，詳細看具體資訊，一般能找到問題，如果不能，自行 google