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打开

里面有两个文件