## 1. 准备工作 ### 1.1 版本环境约定 游戏版本环境包括： 1. 开发环境 dev 开发过程中使用的环境，用于开发组内功能开发，接口联调/自测等。 2. 测试环境 test 开发将自测完成的功能能行提测，测试同学需要用到的测试环境，用于测试新功能/bug回归等。 3. 预发布环境 pre 1. 测试功能完成以后用于准备上线的发布环境，进行线上跟测。针对测试环境的局限性，对接线上数据进行真实环境的实测。 2. 进行灰度发布，减少由于新版本问题造成的线上大面积瘫痪。 3. 当出现问题以后进行快速版本回退。 > 需要注意不要产生脏数据。 > > 需要注意新旧版本兼容性问题，新功能导致的字段增加，数据经验表等变更造成的数据异常。 4. 生产环境 prod 线上环境，正式对外开放的环境。 ### 1.2 权限划分 | | dev | test | pre | prod | | :--: | :--: | :--: | :--: | :--: | | 开发 | ✅ | | | | | 测试 | ✅ | ✅ | | | | 运维 | ✅ | ✅ | ✅ | ✅ | | | | | | | ### 1.3 版本号约定 需要版本号进行约定的主要有 1. laya引擎/lib/sdk版本号 我们每年都会有新的游戏项目进行开发。同时也有很多游戏进行停止更新，由于引擎本身的新功能更新，我们也需要进行跟进，因此线上必然会存在多个引擎版本，同样我们所用到的独立的lib库和sdk包也会有更新，我们把这类统称为库文件，我们需要对这类文件进行一定的命名规范，以保证库文件在线上不会引起冲突。 存放规范为按文件命名或者按文件夹命名 > core/库名-版本号(.min).js > > core/库名-版本号/*(.min).js 2. 游戏版本号 游戏版本号用于版本提测/发布/回退的唯一标识。 > 版本号格式为 *0.0.0.0.xxxxxx* 或者 0.0.0.0 和xxxxxx两个字段分开标识 前3位为主版本号,第4位保留用于bugfix使用，由产品需求定义，第5位表示构建版本号，每次构建都会产生一个唯一标识，可用yymmddno格式定义。 > yymmddno 表示年月日和当天的第几个构建版本 3. 资源版本号(待定，目前按文件夹进行版本规划) 资源版本号用于区分每个游戏版本所需要的游戏资源，包括图片/图集/音频/视频/动画/配置文件等资源。每次发布都需要生成一份资源列表用于资源动态加载和资源映射。 发布时使用md5对游戏资源进行处理，用于避免资源变更时前端浏览器有缓存，导致资源更新不及时。 > 资源版本号可使用yymmddno标示，资源版本文件用文件名加版本号来标识，version-yymmddno.json，避免线上环境可能的覆盖式更新造成版本文件被覆盖，不能回退的问题。 资源发布有按文件和按文件夹进行资源管理更新，我们可以选用一种。 4. 构建版本号 每次构建都会产生一个版本号，从0开始，可顺序增加，或者按每天重置，顺序增加。 5. 接口版本号 待定（改动量不大的情况下通过修改接口名即可） ### 1.4 版本文件目录组织结构 ```shell root ├── core │ ├── laya-1.8.6 │ │ ├── laya.core.js │ │ └── laya.ui.js │ └── libs │ └── stargame │ └── starGame-SDK-1.0.2.js └── game └── v2.0.1 ├── bin │ └── js │ └── game.min.js ├── index.html └── res └── assets ├── sheets │ ├── xxxx.png │ └── xxxx.st ├── sounds │ └── xxxx.ogg ├── spine.d │ └── anim └── version_xxxx.json ``` ### 1.5 完整流程 ```mermaid graph LR; id1((开发者)) --> id2[test包本地构建] --> id3[上传] --test分支--> id4((gitlab版本库)) id5((jenkins操作者)) --> id6[拉取dev] -.test分支.- id4((gitlab版本库)) id6[拉取test] --> id7[同步] --> id8(测试服务器) id6[拉取test] --> id9[推送] --prod分支--> id4((gitlab版本库)) id5((jenkins操作者)) --> id10[拉取prod] -.prod分支.- id4((gitlab版本库)) id10[拉取prod] --> id11[同步] --> id12(预发布服务器) id10[拉取prod] --> id13[同步] --> id14(生产服务器) ``` ## 2. 版本打包 ### 2.1 版本发布测试流程 ```mermaid graph TD 开始构建 --> 读取当前版本号 --> 读取构建版本号 --> 生成新的构建版本号 --> 更新版本配置 --> md5化 --> 生产资源版本文件 --> 编译 --> 发布到dist目录 -->回写构建版本文件 --> 提交编译文件和资源文件到gitlab相应分支并打tag --> 调用操作jenkins的脚本进行发布测试 ``` ### 2.2 gitlab版本库 1. 建立资源版本库，分dev/test/prod3个分支，用于提交版本。 ```mermaid graph LR ROOT --> dev ROOT --> test ROOT --> prod ``` 2. 在版本构建机上进行代码拉取和编译，提交到相应的开发测试分支，并通过jenkins进行发布到测试环境。 3. 当测试完成以后，将测试分支提交到prod分支，通过jenkins进行发布。 ## 3. 测试/同步/发布流程 1. 拉取dev分支发布到测试环境。 ```mermaid graph TD 拉取dev分支代码 --> 同步测试服务器相应游戏版本目录 --> 更新测试环境版本管理数据 --> 进行版本切换 --> 进行测试 ``` 2. 将测试分支提交到prod分支，可通过脚本和后台管理系统进行固化。 3. 拉取prod分支发布到预发布/生产环境。 ```mermaid graph TD 拉取prod分支代码 --> 同步到生产环境相应游戏版本目录 --> 更新生产环境版本管理后台数据 --> 进行线上跟踪测试 --> 进行灰度发布/测试 --> 完整版本切换 --> 发布完成 ``` ## 4. 在线版本管理/回退机制 ### 4.1 在线版本管理 1. 通过版本号映射服务器版本目录。 2. 通过后台控制开关进行灰度发布。 3. 通过白名单设置进行跟踪测试。 4. 通过hash分布进行灰度测试。 ### 4.2 回退机制 通过后台控制选择游戏版本进行版本回退。 ## 5. 版本跟踪和错误日志 1. 在游戏主界面某个区域显示游戏版本号和游戏资源号，方便反馈定位版本 2. 接入错误日志sdk（自研或者使用第三方sdk），用于收集运行报错崩溃。 ## 6. 自动化版本管理最佳实践 1. 版本编译和提交测试 ```shell gulp publish web test ``` 2. 版本发布 ```shell gulp publish web prod ``` H5游戏前端跨域深入解析 Laya中spine的使用和注意点
智能杂货铺
No Leanote account? Sign up now.