不論是用瀑布式亦或是敏捷型開發，開發iOS遊戲到某個階段時，一定有上實機做測試的需求。若是程式人員的開發環境，有著Unity整合XCode的優勢，只需要將Apple iOS Developer上的教學過程確實的走一遍，得到可用的Development Provisioning Profile，接下來在Unity中輸入正確的Bundle Identifier，把USB線連好，在Unity中按下Build and Run，很快地，遊戲就可以藉由XCode發佈到實機上，讓程式人員做簡單的檢視。
但以這樣發佈的方式是很局限的，不但無法將此版本發佈給外部合作人員或相關人員，就算是團隊中的成員，也很難以此方式進行。當然，在Apple的規劃下，除了有Development的方式做發佈，也提供了Distribution的方式做發佈。一但使用了Distribution的方式，就可以在不透過XCode的方式下將遊戲交付給相關的人員。而這樣的發佈方式在Apple的原先的設定下有二種方法。第一種是透過iTunes，也就是說任何相關人員若想要拿到遊戲程式，只要將iOS連至iTune，就可以下載開發中的遊戲App。第二種是OTA(Over the AIR)，名詞聽起來很特別，但實際上就是直接在iOS裝置上，連上網後連到某個位置，以Apple規範的protocol方式下載遊戲。
但是這樣的發佈方式一但有安全上的考量後，就多出了很多複雜的步驟。如果按照Apple原先設定的方式來做Distribution的發佈，整個流程歸納後，會有如下的步驟：
- Step I:
向所有相關人員拿取iOS裝置的UDID
將所有拿取到的UDID加到Apple Provisioning Portal裡
產生相關的Apple ID
確定已產生Distribution Certificate並在要建置的Mac上已安裝
根據上面的資訊產生為了這版本所需要的Ad Hoc Provisioning Profile - Step II: A
將此Distribution Provisioning Profile給予相關人員教導相關人員如何安裝Distribution Provisioning Profile到iTune裡開始建置遊戲版本(.ipa)將此遊戲版本放入某處以供相關人員拿取教導相關人員如何用iTunes安裝ipa - Step II: B
或是OTA的方式將版本發佈(iOS 4.0後)
步驟看起來的確複雜，前面的部份和用Develoopment發佈的方式一樣，只是換成Ad Hoc Distribution，這部份因為已做過一次，難度不高。至於第二個部份，若是期望以iTunes的方式讓相關人員拿取遊戲版本，困難的地方不是在於技術上，而是想法上。要透過iTunes拿取版本，iOS裝置一定要和iTunes做sync，這是很多人不願意做的(沒有人想和公司的電腦sync)。就算是不在意這個問題，確也局限在一定要有iTunes才能進行。
現在的人都習慣透過網路直接做下載的動作，若是所開發的遊戲也能夠以網路直接接下載，會大幅度提相關人員協助的意願，畢竟大部份的相關人員並沒有一定要測試此版本的義務，若是協助時有不方便的情況，多數相關人員會降低意願。基於這樣的考量，現在的Ad Hoc Distribution以OTA的方式進行較為普遍。
OTA的原理很簡單，開發團隊基本上只需要準備好ipa檔和manifest(plist)檔，放在網路空間上，在網頁上連結時放入用itms-services protocol方式的資訊。如下範例所示：
<a href="itms-services://?action-download-manifest&url=http://my-domain.com/manifest.plist">Download App</a>
視情況，server端的MIME也可能需要做調整。
一但開發團隊弄好了OTA的機制，之後每一個版本都可以透過這樣簡單的下載方式讓相關人員輕易的拿取。沒錯，單就以相關人員拿取遊戲版本並協助測試這件事來說，到此都已經完美的解決了。然而，就以遊戲版本被測試這件事來說，才正要開始。
首先，如果相關人員的數量很多，光以分類來看可能就有內部開發人員、外部合作人員、親友團、金主等，每個人所需要接觸到的遊戲版本會有所不同。就算是在建置版本時已經規劃多個版本的層級性，在發佈時也要為了不同的版本做拿取權限上的設計。
給予他人測試是雙向的溝通，每個發佈出去的版本，都希望有回應產生，根據這些回應做討論和改進，才能夠讓遊戲的可玩性、正確性更趨於完美。所以在每個版本發佈後，都需要有一便利的管道讓相關人員可以反應該版本的問題。
最簡單的方式，就是用email。這是會將複雜度轉價給他人自已也很花工的方式，每一封email都要讓他人記錄下是哪個版本，有什麼樣的意見。當開發人員收到信後，一邊需要有某些機制整理不同版本的意見，一邊祈禱email裡的版本沒有被填錯。
另一個開發團隊常用的解決方式就是使用Issue Tracking，讓相關人員回報問題。然而，多數人是不用也不會用Issue Tracking的，將此複雜的機制導入到回報意見上，只會造成他人覺得麻煩，減少了回應的意願。
當然，只要有相對應的資源﹣良好的網站設計加上測試人員流程的訓綀，這些問題要解決也不困難。但是，對於資源有限的團隊來說，如果已經有現成的服務解決上述的問題，又不需要太高的建置成本，一定是有所幫助的。還好在現今網路發達的時代裡，已經有好幾個網路服務或是框架可以使用，徹底的簡化了iOS遊戲(應用)程式的發佈，像是:
這些服務或是框架或多或少的都可以減化版本發佈的過程 or/and 發佈後的管理。
對於使用iTunes發佈或是自行架設OTA發佈的團隊，如果有想要減化發佈的流程和後續可能面臨的管理問題，或是正面臨不知道要用何種形式發佈的開發人員，請務必試試看這些已經存在坊間已久的服務和框架，以最小的資源去處理發佈版本，並將節省的資源有效運用在改善遊戲品質。
小編碎碎念：
如果你覺得這篇文章對你有所幫助，請給我們一個“贊”吧！
使用Unity開發遊戲一段時間，目前在研究已自動化測試的方式協助Unity專案的開發。
沒有留言:
張貼留言