软件开发流程

说明

每个项目的配置模版都只有一套，然后开发、测试、生产的各自有独立配置内容

开发阶段

开发负责，运维配置合并卡点

目标

开发者验证自己开发功能，确保功能没有问题，能够正常打包。

环境

本机、开发机器基于源代码部署。

部署方案

开发者更新并维护代码库中的README.md，其他开发者通过参考详细描述能够进行部署。

配置

开发者需要提供启动需要的最小配置详细说明。

打包

开发者编写启动脚本：scripts/start.sh
开发者编写打包脚本：scripts/package.sh，输出安装，编写要求：
- 安装包包括了启动二进制文件、前端静态资源、以及启动脚本scripts/start.sh等；
- 安装包的命名规则：<project name>-YYYYMMDD-HHMMSS-<最近一次提交的短hash值，7位>.tar.gz，比如：webdav-20260203-153412-8a54401.tar.gz
开发者验证安装包是否能正常启动，解压安装包，进入目录执行scripts/start.sh，能够正常启动

开发者提供打包的脚本（scripts/package.sh，具体请参考webdav/scripts/package.sh）或者方法。

打包操作：在当前项目下执行bash scripts/package.sh 进行打包

包文件的名称格式为：模块名称-YYYYMMDD-HHMMSS-最近一次提交的简短hash值.tar.gz

打包文件放在项目的output目录下，tar.gz文件解压后的名称中只包含模块名称

包名称中的字母全部为小写字母，模块名称可能包含-符号。
日期固定为8位，时间使用24小时方式表示，整体表示打包的时间。
最近一次提交的简单hash值通常为7位。

名称举例：
webdav-20260203-153412-8a54401.tar.gz
yeying-agent-20260203-153412-8a54401.tar.gz

流水

由运维配置代码合并的编译卡点，，确保提交的代码在合并前能够编译通过。

测试阶段

开发为主，运维负责自动化

目标

基于项目的main分支，通过定时任务检测main分支是否有代码更新，确保环境始终都是main分支最新的代码，方便验证最新功能。

检查main分支是否发生变化的通用脚本统一放在deployer/scripts目录下。

编译节点定时脚本：/root/code/deployer/scripts/upgrade/check_code_status.sh (根据配置文件获取对应模块的最新代码，编译的软件包上传到webdav)

环境

测试环境，配置测试域名)测试域名的命名规则如下：https://test-<project name>.yeying.pub

运行目录，默认为/opt/deploy/模块名称

运行节点定时检测脚本 /root/code/deployer/scripts/upgrade/download_packages.sh （根据配置文件下载软件包并进行升级操作）

tar.gz软件包存放路径： /opt/package/

nginx的配置目录： /etc/nginx/config.d/xx.conf

部署方案

运维根据项目的READM.md提供两个脚本：打包脚本和升级脚本，并将脚本存放在<project name>/scripts目录下。

配置

开发者提供测试环境的配置信息

升级

在项目的docs里面维护versions.md文件，记录升级的影响，特别是在升级过程中需要手动介入的地方，可能的影响如下：

数据库变更（增加表、添加字段、修改字段类型以及插入默认数据等等）
配置变更（增加新配置、修改配置名称等）。

运维来更新和维护测试阶段环境的部署信息汇总记录：产品部署

生产部署

由运维同学负责

环境

生产环境，配置生产域名

部署方案

基于deployer部署，以容器化为主。部分情况下可以先非容器，然后改造升级成容器话部署。

社区产品统一放到deployer/product/<your project name>

配置

运维管理生产环境的配置

流水

由运维配置Github打包流水线和创建镜像。

升级

生产环境的升级通常是需要手动介入，基于测试环境升级验证的结果，通过评估后进行的操作。尽管如此，生产环境的升级也应该通过脚本或者常规命令（如果容器的常规操作命令）进行，避免人工更改配置的操作。