发布升级流程
说明
- 每个项目的配置模版都是一套，开发、测试、生产的各自有独立配置内容
开发阶段
目标
开发者验证自己开发功能，确保功能没有问题，能够正常打包。
环境
本机、开发机器基于源代码部署。
部署方案
参考代码库中的README.md详细描述。开发者参考代码库中的README.md详细描述进行部署。
配置
启动需要的最小配置详细说明。开发者需要提供启动需要的最小配置详细说明。
打包
提供打包的脚本或者方法。开发者提供打包的脚本或者方法。
流水
每次代码合并流程设置编译卡点，由运维同学配置，开发者需要确保编译通过。
测试部署测试阶段
目标
基于项目的main分支，通过定时任务检测main分支是否有代码更新，确保环境始终都是main分支最新的代码。确保环境始终都是main分支最新的代码，方便验证最新功能。
环境
Demo环境，配置域名测试环境，会配置测试域名
部署方案
运维提供两个脚本：打包脚本和升级脚本，脚本存放在<project name>/scripts目录下。检查main分支是否发生变化的通用脚本统一放在deployer/scripts目录下。
配置
开发者提供测试环境的配置信息
升级
在项目的docs里面维护versions.md文件，记录升级的影响，比如数据库变更（增加表、添加字段、修改字段类型以及插入默认数据等等）、配置变更（增加新配置、修改配置名称等）。
生产部署
环境
生产环境
部署方案
基于deployer部署，可以先非容器，然后改造升级成容器话部署，社区产品统一放到deployer/product/<your project name>
配置
演示配置
升级
在项目docs里面维护version.md，给出升级的影响，数据库变更、配置变更。
流水
由运维配置Github流水线打包
生产部署
环境
生产环境由运维配置Github打包流水线