CI/CD 自动部署落地方案分享

Git 工作流

{username}/dev => testing => release => master

{username}/dev	testing	release	master
开发分支	测试分支	发布分支	主分支(定版)

提交流程

1. 开发人员日常工作在自己的开发分支上, 如 nieml/dev, 当新功能/特性添加完成后 merge 到 testing 分支
2. 开发人员在 testing 分支进行集成测试, 测试通过后 merge 到 release
3. release 在 CI 部署完成后触发测试事件, 测试人员接收到事件后开始测试
4. 测试通过发送 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

1. 代码格式检查
2. 执行测试用例
3. 生成项目文件及相关依赖文件并打包
4. 生成 docker 使用的镜像并上传到内部镜像库
5. 部署到开发服务器并重启相关服务或更新相关容器

阶段2: testing => release

1. 生成项目文件及相关依赖文件并打包
2. 生成 docker 使用的镜像并上传到内部镜像库
3. 部署到测试服务器并重启相关服务或更新相关容器
4. 触发测试服部署完毕事件, 通知测试人员进入测试

阶段3: release => master

1. 代码格式检查
2. 执行测试用例
3. 生成项目文件及相关依赖文件并打包
4. 生成 docker 使用的镜像并上传到外部镜像库
5. 部署到线上A/B服务器并重启相关服务或更新相关容器

阶段4: 线上更新

3. 测试人员进入, 进行线上测试验收
4. 运维人员发送版本更新事件, 部署服务切换线上 A/B 服务器

k8s 平台管理

不停服更新

使用 k8s service 机制进行 A/B 服切换, 通过 selector 切换后端服务器

负载均衡

使用 service 机制自带负载均衡

配置文件管理

使用 k8s configMap 进行配置文件管理, 根据不同的环境挂载不同的配置文件

日志同步

暂无 暂定使用 k8s 自带的日志管理, 等待评估其他方案

状态监控

暂无 暂定使用 open-falcon 进行状态监控, 等待评估其他方案