Cocos Creator CI CD 策略

Cocos Creator本地構建

通常的ci, cd過程是在一個linux機器上執行。但Cocos Creator不對Linux進行官方維護和支持，而非官方的Cocos Creator Linux鏡像構建出來的包有問題。咱們的項目都pipeline用的是阿里雲服務器，ubuntu系統，所以咱們只能在本地的Mac機子上進行構建。

原來的CI CD策略

一開始，咱們的CI CD策略是本地構建，pipeline部署。具體流程是本地構建，構建出來的文件提交到gitlab進行版本控制，Jenkins pipeline監控到構建文件的變化就進行容器化部署。

該方案存在的本質問題是：構建不受約束，部署隨着構建進行自動化部署，這樣部署也是隨意不受約束的。試想如下幾種狀況：

• A能夠隨時隨地將未通過dev環境的包發佈到QA。
• A本地未合併遠端代碼，就直接將代碼發佈到環境上，環境上運行的代碼版本不是遠端代碼倉庫維護的最新版本。

這倆問題，團隊每次部署前達成一致，加點人爲控制因素是能夠解決。當團隊有了QA，QA每次須要推新版本時，都須要Dev支持......那就好好的支持一下吧

改進的方案實現方式

爲了不QA不定時的找麻煩，固然，更重要的問題是這樣的發佈對於產品環境來講隨時都是定時炸彈，咱們必須改進。目前CI CD策略的痛點是：代碼隨時隨地均可以隨意上生產。項目的侷限是：構建目前只能在本地（也許再搗騰段時間能夠在環境上）。

基於痛點和侷限，改進的方案是：

• 構建依然發生在本地。每次代碼push以前，有一個pre-push事件，對各個環境進行自動構建並提交到遠端。發佈的靜態文件工程做爲Cocos Creator項目的子工程submodule來維護。
• Jenkins監控到代碼的更新，就更新各個環境的即將發佈的cocos發佈的靜態文件。
• 根據須要進行部署

和原方案不一樣的是，在部署以前，增長一個代碼更新的步驟。

Jenkins multi step pipeline

Jenkins multi step pipeline的實現使用了一個視圖插件build pipeline plugin。添加該view的方式，參考：buildPipelinePlugin

build pipeline plugin貌似只支持free style 的pipeline類型，所以全部pipeline都設置爲free-style類型。

1. 增長一個free-style類型的pipeline。

2. 該pipeline的配置：

   • 設置運行節點爲對應的環境節點（Dev, QA, UAT...）
   • 設置post-build action。該pipeline執行完以後執行的任務。這裏添加兩個任務。a. archive 文件，由於接下來執行的pipeline會用到。b. 指定後續構建的pipeline，能夠是自動執行構建，也能夠是手動執行構建。

一些Tips:

• 本地構建注意事項：提交失敗得再次提交
• pipeline的結構組成： 增長learning-game pipeline的緣由是，由於構建須要一些時間，必須確保全部環境的包都已經完成構建以及遠端倉庫更新才能促發pipeline拉代碼，而learning-game代碼庫的更新在全部打包push以後。這樣就能保證代碼一更新，構建的包就已經更新。

項目部署架構：

drawio打開

裏面有兩個文件