Unity專案開發-遞交版本給相關人員

網路上不乏如何使用Unity開發遊戲的文章、討論，但在這些文章中很難找到從專案製作的角度上去看，Unity的專案到底要怎麼樣規劃的資料。雖然專案會因為團隊不同，組成成員的差異和其規模有著很大不一樣架構。

不同於一般的軟體開發，遊戲會由多個不同領域的專家合作，進行協同開發。常見的大項分法大致為程式設計師、企劃人員和視覺設計師等。由於不是純粹的軟體開發人員，故在想法上和專案的執行上，有著很䢛異的風格。故在專案的製作上會比純粹的軟體專案困難許多。

這些架構看起來很不同，但仔細去分析，還是有著一般專案管理不可缺少的元素。所以就算是以Unity進行遊戲的製作，它仍然按照著專案的進程展開。用現在的開發觀點來看，以迭代式的方式進行，配合持續的建置、發佈、測試，完成一個迭代一個迭代的版本。因此，以下會從持續建置的角度先行切入，讓開發者了解到目前的Unity開發生態中，什麼樣的流程是可以導入並協助開發的。

Unity官方在這幾年的努力下，讓Unityh執行檔的雲端建置服務（Unity Cloud Build, 以下簡稱為UCB）變得非常的方便。在沒有使用此服務的情況下，雖然也可以自行搭建Jenkins或是TeamCity等進行相同建置環境的設定，但多平台的建置始終有一定的難度，其中最麻煩的就是如果要建置iOS的ipa檔，只能用Mac OS的環境。光是這點，就很難在坊間的雲端建置上佈署環境，最終也還是以本地端的方式處理是比較可行的。但多平台的設定，使用第三方的Jenkins或TeamCity外掛，碰到問題時，還是很麻煩。而UCB的出現，徹底的簡化這一切。

目前的UCB不簡化了一堆複雜的流程，且前期的設定相當的單純，若沒有太特殊的建置考量，5分鐘內即可完成設定。之後只需將Unity整份專案放到設定時指定的雲端版本控管（如GitHub、BitBucket），則UCB會註冊Webhook，並在版本控管有變動時被知會後開始進行專案的建置動作。建置完成後，不論成功或失敗，也會以email通知，甚至在2016年中時整合了目前專案溝通最主流的服務-Slack，以Slack Bot的方式進行通知其建置的結果。

UCB建置成功後，會產生一連結，點此連結則可進行檔案下載的動作。對於多數的團隊來說，看到建置好的消息後再進一步的自行下載的檔案，而後再發佈到Dropbox或是FTP讓相關人員進行測試，這樣的流程已相當的便捷。然而UCB始終沒有確實的將建置好的版本遞交到相關人員手中，後續的檔案下載都仰賴開發人員自行處理。雖然以職責的化分上，UCB切的恰到好處，但總得有些遺憾，徜若建置後的檔案能自行行的被放到Dropbox上或是FTP上，這樣的流程才會用起來完整。

UCB雖然一直到2017年中都還沒有提供發佈建置檔案到其它雲端服務的功能，但仔細研究後會發現它確實是從很早以前就有提供很完善的機制可以協助後續發佈流程的。其一是UCB建置出來的檔案會放在AWS S3上（暫時存放，約莫為1小時後此連結會失效），其二是建置後可以藉由被註冊的Webhook進行通知。也就是說如果善加利用此二個機制，再配合某些處理，就可以順利的將產出的檔案自動的移到Dropbox或是FTP上。

不過在這裡要特別的提到，就算是以自動化的方式放到Dropbox或是FTP，仍不是好的選擇。不論是Dropbox或是FTP，都只是儲存用的空間，雖然用來擺放建置後的檔案沒有不妥之處，但對於遞效到相關人員手中，仍是欠缺了一層，那就是除非有通知的機制讓其相關人員了解，否則相關人員並不能在新的版本出現於Dropbox或FTP時被知會到。

從iOS app開發上的生態去看，早些年由於app被建置出來後要經過很複雜的方式才能遞效給相關人員，所以那時期出了TestFlight這樣的服務。簡單來說就是從XCode裡產出了iOS的ipad檔後，上傳到TestFlight，則所有相關的人員就會被知會到有新的版本（當然，告知後是否被拿取是二件事），對於拿取新版本進行測試來說是相當方便的。這樣便利的服務最終也被納入了Apple裡，成為內建的一個選項。

回看Unity的執行檔，撇開需要特殊授權的XBox、PS等開發，光是以目前眾多跨平台的生態來說，基本的Windows執行檔（exe）、Mac執行檔（dmg）、iOS的ipa和Android的apk，要能夠找到一個平台可以兼容後續的發佈，就不是很容易的。在目前坊間的服務中，能支持至少這四種執行檔發佈的服務，就HockeyApp莫屬。它不但囊括了前述的四個平台，且它最值得被考量的就是此服務很穩當。這裡的穩當主要是開發遊戲時它有幾個考量點，其一，開發有時需要一段不短的時間，若是前期用的服務到後來消失，還要找替代方案，會很花時間，若是能夠有一長期可使用的服務，是很重要的考量因素之一。而另一點則是它的安全性，每個網路的服務都會存在安全的風險，若是能將此風險降至最低，也是很重要的考量因素。

對於這二點可能有的疑慮，在了解HockeyApp的背景後，應該可以一掃而空。HockeyApp在前幾年時已納入到Microsoft的旗下，有著軟體業巨擘的加持，是可以放心使用的。

HockeyApp的使用上如同其它眾多的發佈服務（TestFlight等），沒有太複雜的設定，就算是第一次才接觸到發佈服務的開發者，應該在二個小時內，也可以順利的設定好並完成其發佈後拿取檔案的流程。大致來說，就是將檔案上傳到HockeyApp，它就會進行進一步的通知，告知相關人員。

這裡，稍為談一下有發佈服務和沒有的情況下有什麼不同。如果只從被知會有新的檔案後進行拿取的角度去看，則和直接使用UCB則有著一樣的功能。但發佈服務不但有知會新版本的功能（最基本的功能就是能知會相關人員），它還有版本的控管，這裡的版本控管指的是被建置出來的檔案，而非程式碼的控管。如果有需要之前的版本，可隨時取回使用。而UCB，並不做版本的控管，就連建置後的產出物也只保留一個小時的時間，除非開發人員自行維護（存下）某個建置後的版本，不然拿取之前的版本是有些困難的。

除了保留版本外，另一個發佈服務重要的功能就是在於發佈給誰，某些版本要遞交給A組人員，有些版本要交付給B組人員。透過一些稍為花時間設定，則可以達到交付於不同相關人員的需求。HockeyApp裡有著非常詳盡的文件說明，也有開發者的討論可供參考。甚至是不明白的地方也可寫信發問，自身在使用HockeyApp上就和其對外技術人員通過幾次信，獲得良好的協助。

回到正題，從檔案移動的進程來看，UCB產出一個檔案放在某處，若能以某種方式將此檔案丟給HockeyApp，且該有的設定也都弄好後，HockeyApp會將後續的發佈、控管處理掉，當整個流程串起來後，開發的過程就會相當的順利。

但要怎麼將UCB建置的檔案（自動地）丟給HockeyApp？在網路上打上了關鍵字後，可以看到這篇Unity的討論。順著前述的檔案進程概念，該開發者在Heroku上架了一個中繼用的服務，每當UCB完成建置後會透過被註冊的Webhook知會該服務，而該服務則會從UCB所給的連結做檔案下載的動作。待檔案下載後，再進行上傳至HockeyApp的程序。如此以來就很巧妙的串連了二個服務，讓建置到發佈能夠自動化的完成。

開發者大方的將其服務的專案開源到GitHub上，有興趣的人可以連過去了解。然而，不知道是UCB連到HockeyApp的流程不普及（有更好的選擇？），又或是該論壇隱藏的很好，並沒有太多人關注，有些可惜。就以自動化的串接二個服務，加速開發的流程來說，此開源專案真得有很大的幫助，花些時間去了解會有很大助益的。

從持續建置到發佈（CI to CD）的歡點上去看，串連UCB和HockeyApp確實的完成了這一塊，讓專案的開發更加的順暢且符合現代的開發流程。對於用了UCB的開發團隊來說，加入HockeyApp能讓流程更完整。而對於還未使用UCB的團隊，也請務必先行導入UCB的流程，體驗到持續建置所帶來的改變。