Git 工作流
{username}/dev => testing => release => master
| {username}/dev | testing | release | master |
|---|---|---|---|
| 开发分支 | 测试分支 | 发布分支 | 主分支(定版) |
提交流程
- 开发人员日常工作在自己的开发分支上, 如 nieml/dev, 当新功能/特性添加完成后 merge 到
testing分支 - 开发人员在
testing分支进行集成测试, 测试通过后 merge 到release release在 CI 部署完成后触发测试事件, 测试人员接收到事件后开始测试- 测试通过发送
pass事件,Git 自动 merge 到master分支并打版本tag
注意事项
release分支只允许testing分支进行合并master分支禁止合并一切未经测试及开发&测试分支的代码- 日常工作时禁止开发人员直接提交非开发分支外的所有分支
- 开发人员每天开始工作之前应先从
testing分支执行 merge 动作, 提前避免集成发生冲突 - 当已发布的版本出现bug时, 开发人员从
master分支新建{username}/hotfix分支进行处理, 处理完成及测试通过后合并进master并删除{username}/hotfix分支
CI/CD 自动化部署
| {username}/dev | testing | release | master |
|---|---|---|---|
| - | 开发(集成)服务器 | 测试服务器 | 线上A/B服务器 |
阶段1: {username}/dev => testing
- 代码格式检查
- 执行测试用例
- 生成项目文件及相关依赖文件并打包
- 生成 docker 使用的镜像并上传到内部镜像库
- 部署到开发服务器并重启相关服务或更新相关容器
阶段2: testing => release
- 生成项目文件及相关依赖文件并打包
- 生成 docker 使用的镜像并上传到内部镜像库
- 部署到测试服务器并重启相关服务或更新相关容器
- 触发测试服部署完毕事件, 通知测试人员进入测试
阶段3: release => master
- 代码格式检查
- 执行测试用例
- 生成项目文件及相关依赖文件并打包
- 生成 docker 使用的镜像并上传到外部镜像库
- 部署到线上A/B服务器并重启相关服务或更新相关容器
阶段4: 线上更新
- 测试人员进入, 进行线上测试验收
- 运维人员发送版本更新事件, 部署服务切换线上 A/B 服务器
k8s 平台管理
不停服更新
使用 k8s service 机制进行 A/B 服切换, 通过 selector 切换后端服务器
负载均衡
使用 service 机制自带负载均衡
配置文件管理
使用 k8s configMap 进行配置文件管理, 根据不同的环境挂载不同的配置文件
日志同步
暂无 暂定使用 k8s 自带的日志管理, 等待评估其他方案
状态监控
暂无 暂定使用 open-falcon 进行状态监控, 等待评估其他方案